Embedding SVG with img, object, and embed in HTML

You will learn the practical differences between embedding an SVG as an image, as a document, or through a legacy embedding element. You will also learn which option is usually best, how server MIME types affect SVG delivery, and how to provide useful fallback and accessible text.

SVG is an image format based on XML. Unlike a raster image such as PNG or JPEG, an SVG can contain shapes, text, CSS, and sometimes scripts.

The HTML element you choose determines how the browser treats the SVG:

• <img> treats the SVG as an external image resource. It is the usual choice for icons, logos, illustrations, and other non-interactive graphics.
• <object> loads the SVG as a separate embedded document. This can be useful when the SVG needs its own internal interactivity, styles, or script.
• <embed> also embeds external content, but it has fewer advantages than <object> for modern HTML and has no useful built-in fallback content.

For most pages, prefer <img> for an external SVG file. It has simple markup, works with responsive-image patterns, and is familiar to assistive technology when given appropriate alt text.

A separate but important issue is the HTTP response header sent by your server. An SVG file should normally be served with:

Content-Type: image/svg+xml

That header is configured on the web server, CDN, or hosting platform—not by adding a type attribute to <img>. A browser may still display SVG in some setups with an incorrect type, but correct server configuration avoids compatibility and security problems.

Think of an SVG file as a drawing stored in a separate folder.

• <img> is like placing a framed copy of the drawing on a wall. Visitors can see it, but they do not enter the drawing to interact with its internal parts.
• <object> is like installing a small display room containing the drawing. The drawing can have its own environment and internal behavior, and visitors can see a notice outside if the room cannot be opened.
• <embed> is an older, simpler way to place that display room, but it gives you less control over what happens when it fails.

Choose the framed copy (<img>) unless you specifically need the display room (<object>).

For a typical logo or illustration, use <img>:

<img src="images/company-logo.svg" alt="Acme Company">

• src is the path or URL to the SVG file.
• alt describes meaningful images for people using screen readers.
• If the image is purely decorative, use an empty alternative text value:

<img src="images/decorative-wave.svg" alt="">

You can set dimensions in HTML or CSS:

<img
  src="images/chart.svg"
  alt="Monthly sales increased from January to March"
  width="640"
  height="360"
>

Use <object> when the SVG itself needs to remain a separate document, such as an interactive diagram:

<object
  data="images/floor-plan.svg"
  type="image/svg+xml"
  width="800"
  height="500"
>
  <img src="images/floor-plan.png" alt="Office floor plan">
</object>

The content between <object> and </object> is fallback content. It can be displayed if the SVG object cannot be loaded or supported.

<embed> syntax is:

<embed
  src="images/floor-plan.svg"
  type="image/svg+xml"
  width="800"
  height="500"
>

Although valid HTML, <embed> is usually not the preferred option for SVG because it cannot contain fallback HTML. Use <img> for ordinary graphics and <object> only when its document-like behavior is needed.

Consider this ordinary SVG image:

<img
  src="/assets/rocket.svg"
  alt="Rocket launching from a platform"
  width="320"
  height="240"
>

When the browser processes this markup:

1. It reads the <img> element in the HTML document.
2. It requests /assets/rocket.svg from the server.
3. The server returns the file, ideally with Content-Type: image/svg+xml.
4. The browser parses the SVG and renders it inside the image box.
5. The width and height reserve space for the image, reducing layout movement while it loads.
6. A screen reader can use the alt value to announce the image's purpose.

Now consider an object with fallback:

<object data="/assets/map.svg" type="image/svg+xml" width="600" height="400">
  <img src="/assets/map.png" alt="Map showing the store location">
</object>

1. The browser tries to load map.svg as an embedded SVG document.
2. If it can load and display it, the SVG is shown.
3. If it cannot, the nested PNG image is available as fallback content.
4. The fallback should communicate the same essential meaning as the SVG whenever possible.

• Brand logos: Use <img> with clear alt text, such as alt="Northwind".
• Decorative interface icons: Use <img alt=""> when nearby text already conveys the meaning, or consider inline SVG when you need to style icon paths.
• Product illustrations and diagrams: Use <img> when users only need to view the artwork.
• Interactive maps or technical diagrams: Use <object> if the standalone SVG contains clickable regions, internal styles, or scripts and you deliberately want it to function as a separate document.
• Email or old-browser support requirements: Supply a PNG fallback where SVG cannot be relied on. Test the actual environments that matter to your users.
• Content management systems: Store SVG assets in a public asset directory and reference them with <img>, while ensuring uploads are sanitized and served safely.

In modern codebases, developers commonly choose one of these patterns:

External SVG as an ordinary image

<img src="/assets/icons/search.svg" alt="Search">

This is the default for an independent asset. It keeps the page markup small and lets the browser cache the file.

Decorative external SVG

<img src="/assets/shapes/blue-curve.svg" alt="">

An empty alt value tells assistive technology that the artwork is decorative rather than meaningful content.

Responsive layout with CSS

<img class="hero-art" src="/assets/hero.svg" alt="A developer reviewing a dashboard">

.hero-art {
  display: block;
  width: min(100%, 48rem);
  height: auto;
}

Fallback when it is genuinely required

<object data="/assets/diagram.svg" type="image/svg+xml" width="700" height="420">
  <img src="/assets/diagram.png" alt="Diagram of the order-processing workflow">
</object>

Avoid adding browser-detection code by default. Current browsers support SVG broadly, so feature detection and DOM replacement add complexity for most sites. If a project supports a specific legacy browser or constrained renderer, test it and provide a fallback asset based on that documented requirement.

Also treat SVG uploads carefully. SVG is XML and can contain active or external content. Production systems often sanitize user-provided SVG files or disallow them, depending on the threat model.

Adding type to <img> and expecting it to fix the server response

<!-- Unnecessary for an img element and does not configure the server. -->
<img src="logo.svg" type="image/svg+xml" alt="Acme">

The important MIME type is the HTTP Content-Type header returned for logo.svg. Configure the server or hosting service to send image/svg+xml.

Omitting alternative text for meaningful images

<!-- Incomplete when the logo or diagram communicates meaning. -->
<img src="logo.svg">

Provide concise alt text:

<img src="logo.svg" alt="Acme">

Use alt="" only for decorative images.

Using <object> for every icon

<object data="check.svg" type="image/svg+xml"></object>

<object> creates an embedded document context and is unnecessarily heavy or awkward for ordinary images. Prefer <img> for simple icons and artwork.

Expecting external SVG paths to be styleable from page CSS

/* This generally cannot select a path inside an SVG loaded by <img>. */
img path {
  fill: red;
}

An SVG loaded through <img> is not part of the page's DOM. If you need to change individual SVG paths with your page CSS or JavaScript, use inline SVG or a suitable component/build process.

Using <embed> while needing fallback content

<embed src="diagram.svg" type="image/svg+xml">

<embed> is a void element, so you cannot place meaningful nested fallback markup inside it. Use <object> when fallback content is essential.

Forgetting intrinsic sizing

An SVG should usually include a viewBox, and ideally sensible dimensions, so that it scales predictably. In HTML, specifying width and height can also reserve layout space before the resource finishes loading.

<img> versus inline <svg> is often the most important modern decision:

• Choose <img> when the SVG is a reusable file and you only need to display it.
• Choose inline <svg> when you need to change fills, strokes, labels, or individual shapes using the page's CSS or JavaScript.

<!-- Default: external SVG image -->
<img src="image.svg" alt="Description of meaningful image">

<!-- Decorative SVG -->
<img src="decoration.svg" alt="">

<!-- SVG as an embedded document with fallback -->
<object data="diagram.svg" type="image/svg+xml" width="600" height="400">
  <img src="diagram.png" alt="Description of diagram">
</object>

<!-- Valid but usually not preferred -->
<embed src="diagram.svg" type="image/svg+xml" width="600" height="400">

• Prefer <img> for normal SVG graphics.
• Use <object> only when you need an embedded SVG document or nested fallback content.
• Avoid <embed> unless you have a specific reason.
• Serve .svg files with Content-Type: image/svg+xml.
• type="image/svg+xml" is relevant on <object> and <embed>; it does not replace correct server MIME configuration.
• Use descriptive alt text for meaningful images and alt="" for decorative ones.
• Use inline <svg> if page CSS or JavaScript must manipulate the SVG's internal elements.

Should I use <img> for SVG files?

Yes. <img> is normally the best choice for displaying a non-interactive external SVG, such as a logo, icon, or illustration.

Does an SVG image need type="image/svg+xml" on <img>?

No. <img> does not need it. Instead, ensure your server sends the SVG file with the HTTP header Content-Type: image/svg+xml.

When should I use <object> for an SVG?

Use <object> when the SVG needs to behave as a separate embedded document or when you need HTML fallback content nested inside the element.

Is <embed> recommended for SVG?

Usually no. It is valid, but <img> is simpler for images and <object> offers fallback content when document embedding is required.

Can I change an SVG's fill color with CSS when it is loaded through <img>?

Not by selecting the SVG's internal paths from the containing page. Use inline SVG when you need direct CSS or JavaScript control over individual SVG elements.

Do I still need Modernizr to detect SVG support?

For most modern web projects, no. SVG support is broadly available. Use feature detection or image fallbacks only when you have a known requirement to support an older or specialized browser.

What fallback should I provide for SVG?

If you must support an environment without SVG, a PNG fallback that conveys the same information is a common choice. <object> can contain that fallback directly; otherwise, your application can choose an alternate image source.

Is it safe to allow users to upload SVG files?

Treat user-provided SVG as potentially active content. Sanitize it carefully or restrict uploads according to your application's security requirements.

• Inline SVG — Lets HTML, CSS, and JavaScript directly access SVG elements.
• HTML image accessibility — Explains alt text, decorative images, and meaningful alternatives.
• HTTP Content-Type headers — Covers how servers identify resources such as image/svg+xml.
• Responsive images and CSS sizing — Helps SVG assets scale without distorting layouts.
• Progressive enhancement — Provides a strategy for fallbacks when a feature is unavailable.
• Content Security Policy (CSP) — Relevant when controlling which image and embedded resources a page may load.
• Web application security — Important when accepting or serving untrusted SVG uploads.