SVG optimization: where the bytes hide and what to cut
· 4 min read
Optimize SVG for the web with measured proof: a real editor export cut 51.6% by SVGO, where the bytes hide, delivery choices, and a pre-ship checklist.
- SVGO cut a real editor-exported SVG by 51.6% in one command
- The savings survive compression: 49% smaller even after gzipping both files
- Editor metadata, precision digits, and unused definitions are where the bytes hide
- Inline SVG gains CSS control; external files gain caching; pick per use case
Why SVG optimization still matters
Vector graphics scale perfectly and stay crisp on every display, which is why MDN's SVG overview calls the format ideal for icons, charts, and interface graphics. What the format does not do automatically is stay small: design editors export verbose files carrying metadata, redundant precision, and editor-specific namespaces that browsers parse but never display. The SVG 2 specification defines a compact grammar for shapes and transforms; most of what bloats an export lives outside that grammar, which is exactly where optimization cuts.
To measure rather than assert, we grabbed a genuine editor-exported SVG from Wikimedia Commons, the classic 10 KB Example.svg written in Inkscape's chatty style, and ran it through SVGO with multipass enabled:
| Version | Raw bytes | Gzipped bytes |
|---|---|---|
| Original export | 10,009 | 4,776 |
| After SVGO multipass | 4,841 | 2,434 |
| Reduction | 51.6% | 49.0% |
The right-hand column answers the skeptic's question: does minification matter after HTTP compression? On this real file, yes, nearly the entire saving survived gzip, because the removed content was genuinely redundant rather than merely repetitive. The same redundancy logic drives every technique in our guide to compressing images for the web.
Where the bytes actually hide
- Editor metadata: RDF licenses, Inkscape version strings, and named layers that render nothing
- Path precision: coordinates like 207.66149703 carry six decimals when three or fewer render identically
- Unused definitions: gradients, filters, and symbols left over from deleted artwork
- Collapsed groups: nested transform groups that multiply into nothing visible
- Default attributes: fill-rule values and stroke settings equal to the defaults anyway
The optimized file from our run demonstrates the result: a single line of SVG with rounded path data, no namespace declarations beyond the required one, identical rendered pixels, and 4,841 bytes where the original weighed 10,009. Same picture, half the bytes.
SVG optimization tooling: one command and one click
New to authoring SVGs at all? MDN's tutorial covers the building blocks first. SVGO remains the standard command-line optimizer, and its plugin list maps one-to-one onto the byte categories above. A sensible default invocation runs npx svgo icon.svg --multipass, with the multipass flag re-running until size stops shrinking. Guard rails exist for good reason: aggressive plugins can strip accessibility attributes or classes your CSS depends on, so review the diff once for critical brand assets before adopting the config everywhere.
Prefer not to install anything? The SVG optimizer runs the equivalent cleanup in your browser, showing before and after sizes instantly, and the SVG path editor helps hand-tune path data when automation rounds too aggressively.
Delivery decisions: inline versus external
Inline SVG markup enters the HTML directly, inheriting page CSS and staying styleable per instance, at the cost of bytes repeated on every page load and no separate caching. External .svg files cache across visits and keep HTML lean, but styling hooks require CSS custom properties or currentColor tricks. The MDN guide on applying SVG to HTML covers the mechanics of both approaches. Rule of thumb from practice: icons repeated across a UI inline via a sprite, large illustrations external and cached.
One delivery trap deserves its own warning: embedding SVG as a base64 data URI inflates bytes by roughly a third before compression and defeats caching entirely. Our base64 image encoder covers when data URIs earn their keep, which is rarely for SVG above icon size.
A pre-ship checklist
- Run the optimizer with multipass and record the before and after sizes
- Confirm aria-labels and titles survived if the SVG conveys meaning, per WAI's image guidance
- Set explicit width and height or aspect ratio to prevent layout shift
- Preserve the viewBox attribute; SVGO's removeViewBox plugin once stripped it by default and broke responsive scaling
- Check the file renders identically at 16 pixels and full size
- Choose inline versus external deliberately based on styling and caching needs
Conclusion: half the bytes, zero visual cost
Our real-world measurement settles the effort question: one command removed half the bytes from a genuine editor export, and the savings persisted after compression. That is the whole argument. Optimize every SVG before it ships, keep accessibility attributes intact through the process, and choose delivery per use case. The SVG optimizer makes the whole routine a thirty-second habit.
Written by
Tom Whitfield
I start by splitting the formats into two groups, because most of the confusion comes from treating them alike. Lossless formats keep every pixel. Converting between lossless formats is safe in principle, though there is a catch: an image with an alpha channel cannot be represented in a format without one, and transparency silently becomes a background colour. That is the one conversion to check before you run it on a batch.
Lossy formats discard information on purpose. Converting a JPG to WebP re-encodes an already-encoded image, and the result carries the artefacts of both encodings. There is no reason to do that unless you need the format, and if you have the original you should convert from it every time. Colour profile is the other half.
An image with an embedded profile displayed on a system without one will have its colours shifted, and the shift is far more visible than the compression artefact people expected to see. Converting without handling the profile is the most common way an otherwise fine conversion looks wrong. I cover the format decisions by use: a photograph for display, a logo with transparency, an image with text in it where artefacts are unacceptable, and an image destined for print where colour space changes everything.
Batch conversion is where mistakes get expensive. I write about previewing a single file and reading the output size before running the directory. One more caution about alpha. Converting a transparent image to a format without transparency produces a background colour chosen for you, usually black, and on a dark page that reads as a black rectangle around the subject rather than as an error.