Export an icon from Figma or Illustrator and you'll typically get a file between 1.5KB and 6KB. Less than a third of that is actually the drawing. The rest is editor metadata, default attributes, and XML ceremony that a browser neither needs nor uses. Stripping it down to just the render-critical parts is SVG optimization — and done carefully, it can drop file size by 70% without changing a single pixel.

Done carelessly, it breaks the image, the accessibility tree, or the interactivity you added in code. Let's walk through what's safe, what's risky, and which tool to reach for when.

What's Always Safe to Strip

Editor-specific namespaces

Inkscape writes elements with an xmlns:sodipodi and xmlns:inkscape namespace, used for things like layer names, selection state, page color, and other editor-internal state. Illustrator's equivalents live under xmlns:sketch, xmlns:graffle, and a few others. Figma writes cleanly by default but older tools add their own. Browsers ignore all of this — strip it.

XML prolog and doctype

An exported SVG typically starts with:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "...">

These are required for standalone .svg files served with image/svg+xml Content-Type. They are not needed when the SVG is inlined into HTML (the much more common case today). If you're using the SVG as a React component, an inline block, or a data URI, strip them.

Editor-exported <metadata>, <title>, and <desc>

Many exporters dump license text, Creative Commons RDF, and other metadata into the file. Almost always safe to remove. <title> and <desc> — see the accessibility section below; they're mostly auto-generated junk like <title>Untitled</title>.

Default attribute values

version="1.1" is the default when unspecified; drop it. xmlns:xlink is the default namespace for <use> references and can go if you don't use xlink:href. standalone="no" is also the default.

Whitespace and comments

Same story as XML in general. Between tags: gone. Comments: gone.

Aggressive but Often-Safe Optimizations

These go beyond what our browser-based SVG Minifier does. Dedicated SVG tools like SVGO handle them with plugins you can enable case-by-case:

  • Path data precision reduction.d="M12.345678 67.890123 L ..." is usually overkill — two or three decimals are visually indistinguishable at icon scale. SVGO's cleanupNumericValues reduces precision safely.
  • Remove unused <defs>. When a design tool exports, it sometimes emits gradient or filter definitions that aren't referenced anywhere. Drop them.
  • Merge paths. Multiple adjacent <path> elements with the same fill can combine into one.
  • Convert shapes to paths.<rect> can be rewritten as <path d="...">. Sometimes shorter, not always — depends on the rect.
  • Remove hidden layers. A layer with display:none doesn't render but still ships.

Destructive Optimizations to Watch For

Removing IDs

If your CSS or JS references #myIconStroke to color or animate a path, a minifier that strips "unused" IDs will break the interaction. Some SVGO configurations remove IDs by default and people find out the hard way. Configure the cleanupIds plugin with a preserve list, or disable it.

Removing viewBox

Without viewBox, responsive scaling breaks. An SVG with fixed width and height attributes but no viewBox doesn't adapt to container size via CSS. Rarely stripped by modern tools, but double-check.

Stripping <title> when it IS the accessibility label

Here's the nuance: most <title> elements in exported SVGs are editor junk (<title>Untitled</title>). But a deliberately-authored SVG icon might use <title>Close dialog</title> as its a11y label. Stripping it removes the accessible name for screen-reader users.

The practical answer: don't rely on embedded <title> for accessibility. On the consuming side, add role="img" and aria-label or aria-labelledby on the inline SVG or the wrapping element. That's more reliable and survives optimization.

Coordinate precision too low

Reducing path precision from 6 decimals to 0 decimals visibly degrades the shape on anything larger than 24px. Keep 2–3 decimals; that's the sweet spot.

Where You'll See the Biggest Wins

Icon sprite sheets

A sheet of 50 icons at 1.5KB each is 75KB. Optimized they might be 25KB — a 3x reduction that shows up in every page load. Sprite sheets served via <symbol> / <use> benefit from both SVGO-level optimization and gzip.

CSS background-image data URIs

When you base64-encode an SVG to use as a CSS background, every byte is tripled (base64 adds ~33% overhead). Minifying the SVG first saves you 1.33x whatever you cut from the source. The difference between a 300-byte SVG and an 80-byte SVG, base64-encoded, is the difference between useful inline and bloated.

React / Vue component imports

When a bundler imports an SVG as a JSX component, the file contents become part of your JS bundle. Optimizing the SVG directly shrinks the JS bundle. Frameworks like svgr wire SVGO into this pipeline automatically — make sure the plugin list is sensible.

Our Tool vs SVGO

The SVG Minifier in the tools site does the conservative first pass:

  • Drop XML prolog, doctype, default attributes.
  • Drop editor-specific namespaces (sodipodi, inkscape, sketch, graffle, cc, dc, rdf).
  • Drop <metadata>, <title>, <desc> blocks.
  • Collapse whitespace between tags.
  • Strip comments.

For a one-off icon optimization, that's plenty and it runs entirely in your browser in milliseconds. For a production pipeline processing hundreds of icons at build time, use SVGO with a curated plugin list — its path-data precision reduction, default-attribute removal, and shape-to-path conversion give you another 20–40% beyond the basic pass.

Check the Output Visually

Every SVG optimization pipeline should end with a visual diff. Open the before and the after side by side. At display sizes you actually use (16px, 24px, 48px, 96px), they should be indistinguishable. If you see jaggies, stepped curves, or color shifts, back off the precision reduction or the plugin that caused it.

Tools like SVGOMG show the visual diff alongside the byte-savings counter, which is the right feedback loop.

Bottom Line

SVG optimization is one of the best byte-per-effort wins in frontend performance. The safe pass — strip editor metadata, drop default attributes, collapse whitespace — is a no-brainer. Use our SVG Minifier for a one-off icon, and SVGO for a production pipeline. Always visual-diff before shipping. And keep accessibility labels on the consuming side, not embedded in files that get stripped.

Read next

Related Guides