Embedding (<embed>, <object>) — HTML

<embed> and <object>

Most external content on the web today is embedded with dedicated elements like <img>, <video>, or <iframe>. Before those existed, browsers relied on two more general-purpose elements—<embed> and <object>—to hand off rendering to an external resource or a plugin. They're less common now, but you'll still meet them embedding PDFs, SVGs, and other browser-native or plugin-handled content.

<embed> — Plugin-Style Content

<embed> is a void element (no closing tag, no children) that tells the browser to render whatever is at src using the most appropriate handler—historically a plugin such as Flash or a PDF viewer, and today usually the browser's built-in PDF renderer.

embed.html

HTML

<embed
  src="/files/datasheet.pdf"
  type="application/pdf"
  width="600"
  height="800"
/>

Attribute	Purpose
src	URL of the resource to embed
type	MIME type hint, e.g. application/pdf
width / height	Rendered dimensions in pixels

No fallback content

<embed> is a void element—it cannot contain fallback markup. If the browser can't render the resource, the user sees nothing at all. This is one reason <object> is often preferred for anything important.

<object> — Embedding With a Fallback

<object> serves a similar purpose but is a container element: it can hold fallback content that renders only when the browser cannot display the primary resource. The resource location goes in data rather than src.

object.html

HTML

<object
  data="/files/report.pdf"
  type="application/pdf"
  width="600"
  height="800"
>
  <p>
    Your browser can't display this PDF.
    <a href="/files/report.pdf">Download the report instead</a>.
  </p>
</object>

The paragraph inside <object> only renders if the browser fails to handle the data resource—otherwise it's completely ignored. This makes <object> a safer choice than <embed> whenever you need a guaranteed way for users to still reach the content.

Embedding an SVG With <object>

Unlike <img>, an SVG loaded via <object> keeps its own scripting and CSS context, which matters for interactive or animated diagrams.

svg-object.html

HTML

<object
  data="/icons/logo.svg"
  type="image/svg+xml"
  width="120"
  height="120"
  aria-label="Company logo"
>
  <img src="/icons/logo.png" alt="Company logo" />
</object>

Prefer a modern, purpose-built element when one exists

For images use <img>, for video/audio use <video>/<audio>, and for embedding another HTML document use <iframe>. Reach for <embed>/<object> mainly for PDFs, standalone SVGs, or legacy plugin content.

<embed> vs <object> vs <iframe>

Element	Fallback content	Typical use
<embed>	None (void element)	Quick PDF/plugin embed
<object>	Yes, via child markup	PDF or SVG with a graceful fallback
<iframe>	Yes, via child markup	Embedding another full HTML document/page

Accessibility still applies

Give embedded content a descriptive title or aria-label where supported, and always provide a meaningful fallback (a direct download link is a good default) since assistive technology and older browsers may not render the embedded resource at all.

Embedding Audio/Video the Old Way

Before <video> and <audio> existed, media was almost always embedded with <object> pointing at a plugin (Flash, QuickTime, Windows Media Player), sometimes with a nested <embed> as a fallback for browsers that preferred the simpler tag. You'll still see this pattern in very old codebases or legacy CMS templates.

legacy-media.html

HTML

<!-- Historical pattern — do not use for new projects -->
<object data="movie.swf" type="application/x-shockwave-flash" width="400" height="300">
  <param name="movie" value="movie.swf" />
  <embed src="movie.swf" width="400" height="300" />
</object>

Flash and most legacy plugins are gone

Every major browser removed Flash Player support years ago, and most of the plugin architectures <object> was designed around no longer exist. If you inherit code like the example above, replace it with <video>/<audio> rather than trying to keep the plugin alive.

Handling Load Failures

Because the browser decides at runtime whether it can render an <object>'s resource, it's good practice to test the fallback path deliberately—point data at a deliberately broken URL during development and confirm your fallback content actually appears, rather than assuming it will.

fallback-test.html

HTML

<!-- Temporarily break the path to verify the fallback renders -->
<object data="/files/does-not-exist.pdf" type="application/pdf" width="600" height="800">
  <p>
    Unable to display the PDF.
    <a href="/files/does-not-exist.pdf">Click here to download it</a> instead.
  </p>
</object>

Scenario	What the user experiences
<embed> with a broken src	An empty box—nothing else is shown
<object> with a broken data URL	The fallback markup inside <object> renders instead
<object> where the browser lacks a PDF viewer	Fallback markup renders, same as a broken URL

A direct download link is almost always the right fallback

Whatever the reason an embed fails to render, a plain link to the underlying file lets the user open or download it another way. It's simple, robust, and works in every browser.

<embed> is a void element with no fallback content—use it for simple, non-critical embeds.
<object> uses the data attribute (not src) and supports fallback markup as its children.
Always provide a fallback such as a direct download link for PDFs and other embedded files.
Prefer a dedicated element (<img>, <video>, <iframe>) when one exists for your content type.