SVG Minifier

What actually makes an SVG fat

An SVG file is XML, not pixels. That single fact changes everything about how you optimise it: there is no quantisation table, no colour subsampling, no encoder quality slider. What makes an SVG large is almost always text that has no visual effect.

Where the bytes go in a typical exported SVG

Open a logo exported from a design tool and you will usually find, in roughly this order of weight:

• Editor metadata. <metadata> blocks, RDF descriptions, <title> and <desc> elements that carry the layer name rather than anything a screen reader benefits from.
• Private namespaces. Inkscape writes inkscape:*, Inkscape and older tools write sodipodi:*, Adobe products write their own. None of it affects rendering.
• Excess coordinate precision. A path written as 12.345678901234 renders identically to 12.346 on any display you own. Six unnecessary decimal places per coordinate, multiplied by thousands of coordinates, is real weight.
• Whitespace and newlines. Pretty-printed XML costs bytes for human eyes that never look at it in production.
• Empty groups and unused defs. <g></g> wrappers, unreferenced gradients, clip paths nobody clips with.

None of these are "quality". Removing them is not lossy compression — the rendered output is bit-identical, which is why SVG minification routinely produces double-digit percentage savings with zero visual change.

Why bother if the server gzips anyway

A fair challenge. If Brotli already shrinks your SVG on the wire, does the source size matter? Three reasons it still does:

First, parse cost. The browser has to build a DOM from that XML. Fewer nodes and shorter attribute strings mean less work on the main thread, which shows up on low-end phones long before it shows up in a transfer-size chart.

Second, inlining. If you paste an SVG into your HTML or into a CSS url(), it is no longer gzipped separately — it is part of a document that also gets base64-encoded in some build pipelines, where every source byte costs you 1.37 output bytes.

Third, maintenance. A 3 KB SVG is one a human will actually read and edit. A 40 KB one is a blob nobody touches.

The settings, and what each one risks

Remove comments. Safe. Comments never render. The only edge case is a build tool that uses comments as markers — rare, and you would know if you did this.

Remove metadata, title and desc. Safe for decoration, think twice for meaningful graphics. A <title> element is what assistive technology announces for an SVG used as content. If your icon already has an aria-label or is marked aria-hidden, stripping it costs nothing. If the SVG is the content — a chart, a diagram — keep the title.

Round coordinates. Safe at 2–3 decimal places for anything displayed at screen resolution. Drop to 1 and you may see sub-pixel drift on very large scaled-up output. For a 24 px icon, even 1 decimal place is generous.

Collapse whitespace. Safe, with one historical caveat: whitespace between inline elements can affect layout when an SVG is inline in HTML and inherits text flow. Minifiers that only remove whitespace between tags (not inside <text> content) avoid this.

What this tool deliberately does not do

It will not convert strokes to paths, merge paths, or simplify curves. Those operations do produce further savings, but they change geometry and can shift rendering in ways you need to eyeball. They also risk breaking stroke-based animation. If you need that level of optimisation, use a dedicated build step where you can diff the result visually.

It also will not touch your viewBox, which is worth stating explicitly because removing it is the single most common way to "optimise" an SVG into being non-responsive.

How to sanity-check the result

Two checks, both ten seconds: open the original and the minified file side by side in two browser tabs and flip between them at the same zoom — any geometric change will pop out as movement. Then drag both into a browser and confirm the minified one still scales when you resize the window, which proves the viewBox survived.