SVG Optimiser

The Complete Guide to SVG Optimisation — What It Removes and Why It Matters

SVG files exported from design tools are almost always larger than they need to be. Illustrator, Figma, Inkscape and Sketch all embed additional data into exported SVG files that makes sense for the authoring environment but is completely unnecessary for browser rendering. Understanding what that data is — and what it's safe to remove — helps you optimise more confidently and debug edge cases when something changes unexpectedly.

What does an SVG optimiser actually remove?

The typical SVG exported from Illustrator or Figma contains several categories of unnecessary data:

XML processing instructions and doctype declarations. SVG embedded directly in HTML does not need an XML declaration (<?xml version="1.0"?>) or doctype. These add bytes with no rendering effect when used inline or as an <img> source.

Editor metadata blocks. Illustrator embeds an extensive <metadata> block containing Dublin Core RDF triples, creation timestamps, Illustrator version data and document settings. Inkscape embeds its own namespace (sodipodi:) with editor-specific attributes. Figma embeds a figma:... namespace. None of this affects rendering.

XML comments. Illustrator often includes layer comments and export notes as XML comments (<!-- Generator: Adobe Illustrator ... -->). These are safe to remove from production SVGs though worth keeping in source-controlled originals.

Empty group elements. Complex Illustrator documents frequently export nested g elements that serve only as layer containers during editing. When those layers have no visible content after flattening, the <g> tags remain in the export with no children. Collapsing or removing these has no visual effect.

Unused definitions. The SVG <defs> block contains reusable elements — gradients, filters, clip paths — that are referenced elsewhere in the file. During editing, elements may be added to <defs> and then removed from the visible artwork without the definition being cleaned up. Unused definitions add bytes with no visual contribution.

Default attribute values. SVG has many attributes that have default values when omitted. For example, fill="black", opacity="1", visibility="visible" — any attribute set to its default value can be safely removed. Design tools frequently include these explicitly for legibility, but browsers know the defaults without being told.

Excessive coordinate precision. Path coordinates exported from vector editors often have 6+ decimal places (M 123.456789 456.123456). At typical web display sizes, coordinates rounded to 2 decimal places are visually indistinguishable. Reducing precision to 2dp can significantly shrink path data, particularly in complex illustrations.

When SVG optimisation is and isn't lossless

Most standard optimisation passes are truly lossless — the rendered output is pixel-identical to the original. However, three specific optimisations deserve caution:

Path precision reduction is technically lossy but practically imperceptible at normal display sizes. At extreme zoom (4000%+), sub-pixel differences may be visible in complex paths with tight curves. For SVGs used at print resolution or in technical diagrams where precision matters, keep precision at 3–4dp rather than the default 2.

Comment removal is fully lossless visually, but may remove licensing information embedded as XML comments. If your SVG uses a Creative Commons or other open-source licence that requires attribution to be preserved, either keep comments enabled or ensure the attribution exists somewhere else in your project.

Metadata removal removes Dublin Core and XMP metadata blocks. This has no visual effect, but if your SVG is part of a document management system that reads SVG metadata for cataloguing, keep this pass disabled.

SVG optimisation in web performance

SVG optimisation contributes to web performance in two ways. First, directly: a smaller SVG file takes less time to transfer over the network, particularly noticeable on mobile connections. Second, indirectly: a smaller SVG DOM has fewer nodes for the browser to parse and lay out. Complex SVGs with thousands of path elements can contribute to parsing jank even after transfer — reducing the node count through group collapsing helps here.

SVG files can be additionally compressed with gzip or Brotli at the server level (since they are text-based XML), which typically achieves another 60–80% reduction on top of the optimised size. This is separate from and additional to the optimisation this tool performs. If your web server serves SVGs with Content-Encoding: gzip, the gzip benefit applies to the already-optimised file — so running optimisation before gzip compounds both savings.

SVG optimisation vs SVG conversion to PNG/WebP

SVG and raster formats (PNG, WebP) serve different purposes. SVG should be used for vector graphics — icons, logos, illustrations, charts — where scalability matters. Converting to PNG or WebP makes sense only when the SVG contains complex filter effects or gradients that are slow to render, or when you need a fixed-size image for a specific raster context.

For most icon and logo use cases, an optimised SVG will be smaller than an equivalent PNG at the same visual quality at 2× density, while remaining infinitely scalable. An optimised SVG icon at 200 bytes will look perfectly sharp on a 4K display; an equivalent PNG at 64×64 pixels would need to be 128×128 for Retina and still shows pixelation at larger sizes.

Frequently asked questions