How to optimize SVG files for the web

Begin with the intended use

An SVG used as a static <img> can often be simplified more aggressively than an inline SVG controlled by CSS and JavaScript. Before removing anything, identify what the asset depends on:

• Are classes or IDs used by CSS, scripts, fragment links, masks, gradients, or clip paths?
• Does the SVG contain a title or description needed for accessibility?
• Will the graphic be animated or recolored?
• Must it scale to very small sizes without visible distortion?

Optimization should follow these requirements, not erase them.

Use a useful viewBox

The viewBox establishes the SVG's internal coordinate system and makes responsive scaling straightforward:

<svg viewBox="0 0 240 160" xmlns="http://www.w3.org/2000/svg">
  ...
</svg>

For a responsive inline graphic, fixed width and height attributes may be unnecessary if layout is controlled by CSS. For an image with an intrinsic aspect ratio, keeping dimensions can help the browser reserve space and reduce layout shift. Choose based on how the SVG is embedded.

Remove editor-specific data carefully

Vector applications may add metadata, named-view information, unused definitions, comments, and proprietary attributes. These can increase size without affecting browser rendering. Remove them only after confirming that the file does not need to return to the originating editor with all editing features intact.

Likewise, delete hidden objects and unused gradients, masks, patterns, and symbols, but verify that no url(#id) or href="#id" reference still points to them.

Reduce number precision with visual tests

Coordinates such as 42.638291 may not need six decimal places. Reducing precision can substantially shorten complex path data. The appropriate precision depends on the coordinate scale and final display size.

Small icons are especially sensitive. Rounding a point by half a unit inside a tiny viewBox can move an edge visibly. Compare the optimized result at its intended size and at high zoom before accepting the change.

Simplify without obscuring intent

• Remove attributes that merely repeat an inherited or default value.
• Combine compatible transforms when doing so does not make future editing harder.
• Reuse repeated geometry with symbol and use when the reuse is meaningful.
• Keep a rect or circle instead of converting it to a longer path when no path-specific editing is required.
• Avoid embedding raster images or fonts unless the asset truly needs them.

The smallest possible markup is not always the best source. A few extra characters can be worthwhile when they preserve clear structure and predictable styling.

Preserve accessibility

When an SVG communicates information, provide an accessible name appropriate to how it is embedded. Inline SVG can use a meaningful <title> connected with ARIA. An SVG loaded through <img> uses the image element's alt text.

Purely decorative graphics should be hidden from assistive technology so they do not create noise. Optimization tools should not make that decision without knowing the page context.

A reliable optimization checklist

1. Keep an editable original. Optimize a copy intended for delivery.
2. Record dependencies. Identify IDs, classes, accessibility text, scripts, and animation hooks that must survive.
3. Remove unused content. Delete unnecessary metadata, hidden objects, and unreferenced definitions.
4. Reduce precision gradually. Compare the file at its actual display sizes after each change.
5. Clean presentation attributes. Remove only values that are genuinely redundant in the embedding context.
6. Validate references. Test gradients, masks, clip paths, symbols, and fragment links.
7. Test accessibly. Confirm that informative graphics retain an accessible name and decorative graphics remain ignorable.
8. Serve with compression. Modern hosting platforms normally compress text assets such as SVG over the network.