Optimizing SVG for the web without wrecking it

Too many nodes. A tracer places a point wherever the pixel boundary turns, which on an anti-aliased curve is constantly. A curve that needs four points can get forty.

Excessive decimal precision. Coordinates like 127.38472615 are common in trace output, and the last several digits often describe distances smaller than a pixel at any size the file will be shown.

Duplicate and invisible shapes. Zero-area paths, shapes hidden entirely behind other shapes, leftover clipping rectangles.

Editor metadata. Open a trace output in Inkscape, save it, and you've added a block of Inkscape-specific namespace data that no browser reads.

Inline styles repeated on every element. Fifty paths each carrying the same fill and stroke declarations.

This is the step that makes the rest meaningful, and it takes a minute.

Record three numbers for the original: file size, node count (most editors show this, or count the coordinate pairs in the d attributes), and a screenshot at the size the graphic will actually be used. Then optimize, record the same three, and compare the screenshots side by side at that size.

Without this you're guessing. With it you can tell the difference between an optimization that saved 80% and changed nothing, and one that saved 85% and quietly flattened your curves.

Simplify the paths. This is usually the big one. Path simplification merges redundant nodes while keeping the curve within a tolerance you set. How far you can push it depends entirely on the artwork: a bold geometric mark tolerates aggressive simplification, a detailed illustration does not. Start conservative, compare against your reference screenshot, increase until you see a difference, then back off.

Do it at trace time if your tool lets you. Simplifying during the trace tends to produce better curves than simplifying afterwards, because the tracer still has the original pixel data to work from.

Cut decimal precision. SVGO exposes this as a configurable value. Two or three decimal places suits many web icons and logos, but the right number depends on your coordinate scale and how fine the detail is. It's a parameter to test, not a rule, and it's usually one of the cheapest wins available.

Strip the metadata. Editor namespaces, comments, empty groups, unused definitions. Safe in a file you're shipping.

Remove hidden geometry. Shapes with no area, elements with zero opacity, anything fully covered by an opaque shape above it. Safe in a production copy. Keep in mind that in a working master some of those may be deliberate.

Move repeated styles to CSS. If every path shares a fill, one class beats fifty inline attributes.

This matters more than any single setting. Optimization is lossy and there's no undo once you've overwritten the file.

Keep an editable master, with its layers, its hidden alternates, its structure intact. Export an optimized copy for the web. When the design changes, you edit the master and re-export, rather than trying to reverse-engineer a minified file.

SVGO is the standard. Command line, through a build step, or via the SVGOMG web interface if you want to toggle each optimization and watch the result.

One configuration to watch: removeViewBox strips the attribute that lets an SVG scale responsively. It is not part of SVGO's default preset, but it can be enabled explicitly, and other toolchains that wrap SVGO may configure things differently. If an SVG suddenly stops resizing properly after processing, that's the first thing to check.

Your tracer's settings matter more than any post-processing. A trace with colour count and detail level set appropriately produces a file that needs very little optimization. A trace at maximum detail produces one that no optimizer can fully rescue.

Over-simplification is a real failure mode and it's easy to miss on a large screen.

Check at the size it will be used. A logo optimized while zoomed to 400% can look wrong at 32px in a navbar, and vice versa.

Watch for flattened curves. Aggressive simplification turns gentle curves into straight segments. On a circle this is obvious; on a letterform it shows up as a subtle wrongness you can't immediately name.

Watch the corners. Sharp corners are often the first thing simplification rounds off. A square that's become slightly soft at the corners means you've gone too far.

Rough guidance, not thresholds: a simple icon that lands in low single-digit kilobytes and a typical logo in the low tens are reasonable outcomes. Detailed illustrations run higher and that's fine.

If you're far above what feels right for the complexity of the artwork, the fix is usually upstream rather than in the optimizer. Trace with fewer colours, less detail, or simplify the design itself.

Accessibility. An inline SVG that conveys meaning needs a <title> element, and a decorative one needs aria-hidden="true". Neither costs anything and both are routinely forgotten. Optimizers won't add them for you, and some configurations will strip a <title> you did add unless you tell them not to.

Tracer lets you control the trace before you export, which is the cheapest optimization there is. Free for SVG.