The old embed model pushed complexity onto every host site. A blog or CMS had to know how Flickr, YouTube or another service structured its pages, and those rules broke whenever the provider changed markup.

oEmbed inverted the work. The provider publishes URL schemes and an API endpoint; the consumer submits the URL and gets back a JSON or XML response describing a photo, video, link or rich object.

WordPress shows why the format stuck. By 2015 it had long been an oEmbed consumer, then WordPress 4.4 also became a provider, making ordinary posts embeddable by any oEmbed consumer.

Ask the URL's owner how to embed it

A pasted URL stayed the user's only input.

Providers controlled their own embed HTML, dimensions and safety model.

Consumers could support many services through one request pattern.

WordPress adoption turned millions of sites into both oEmbed consumers and providers.

If every platform wants to be embedded, do not make every host parse every platform. Let the source of truth serve the embed recipe.

oEmbed became the quiet plumbing behind rich link previews and embeds across blogs, CMSs and media services. The important choice was not a clever parser; it was refusing to parse and asking the publisher directly.

FOLLOW THE EVIDENCE

The sources

  1. oEmbed raw.githubusercontent.com
  2. New Embeds Feature in WordPress 4.4 make.wordpress.org