The Complete SVG Optimization Guide

An SVG that looks fine on screen can still be ten times larger than it needs to be. The excess usually comes from four places: coordinates carried to absurd precision, editor metadata that no renderer uses, redundant groups and transforms, and path data that repeats points along a straight line. This guide walks through each source of bloat and the specific techniques that remove it without touching what the artwork looks like.

Why SVG files get large

Vector size is not about how complex the picture looks. It is about how many numbers the file contains and how many digits each number uses. A single path with 20,000 nodes and six-decimal coordinates can dwarf an entire illustration composed of elegant 30-node curves. Design tools frequently emit that kind of file because they round-trip every editor state — named layers, unused swatches, viewport settings, and plugin data.

The best way to understand the problem is to open the SVG in a text editor and look at a path. If you see something like d="M 12.384756 -4.293847 L 12.384756 -4.100000 L 12.384756 -3.900000", you are looking at two distinct costs: numeric precision and unnecessary intermediate points. Removing a few decimal places loses nothing a printer or screen can detect. Removing collinear points loses even less.

Step one: reduce coordinate precision

A machine can distinguish roughly 0.05 of a millimetre. Print at 300 dpi resolves about 0.08 of a millimetre. Yet many exports carry six decimals of a millimetre, which is a sub-nanometre claim. Rounding path coordinates to two or three decimals is usually invisible in output and cuts file size dramatically, because every trailing digit costs one byte in a text format and many paths repeat coordinates hundreds of times.

If your file uses viewBox units where 1 unit equals 1 pixel, two decimals is plenty; if 1 unit equals a millimetre, three decimals is generous. If you are worried about rounding drift across many small segments, apply the rounding to every coordinate once rather than repeatedly optimizing an already-rounded file.

Step two: strip editor metadata

• Comments and descriptions — Inkscape and Illustrator both write history and tool notes that renderers ignore.
• Editor-specific namespaces — sodipodi, inkscape, sketch, and adobe attributes are not needed by browsers or cutters.
• Unused defs — gradients, clip paths, and symbols that nothing references.
• Empty groups and stray elements — zero-size rectangles, anchors, and hidden groups left from editing.

These are safe removals because they do not change the rendering model. The one caution is accessibility: preserved