2026-10-29
An SVG file is markup, which is why compress svg means editing text rather than discarding pixels. Strip the metadata your editor left behind, round the coordinates, drop the defs nothing references, and a 180 KB icon can land under 20 KB with no visible difference. Do it carelessly and you get the other outcome: paths shifted by a pixel, a gradient gone, an animation stuck on frame one. Here is what is safe to delete, which number matters most, and how to check the result before it goes live. The raster side of this comparison is in /blog/lossy-vs-lossless-compression; SVG sits firmly on the lossless end.
Export settings are where the dead weight comes from. Illustrator, Figma and Inkscape all write editor information into the file by default, and the browser reads none of it when drawing the image.
The test is a single question: does the browser need this to draw the picture? If not, it can go. When you are unsure, leave it in. A stray id costs tens of bytes, while deleting the wrong one costs you the whole graphic.
Coordinate precision is where most of the savings live. Exports usually write six decimal places for every point. Two decimals keeps sub-pixel accuracy for icons shown between 24 and 128 pixels, and it removes a large share of the bytes.
On a 300 KB map illustration, going from six decimals to two usually removes about a third of the file. That is a bigger win than metadata cleanup, and it is also easier to get wrong, so always look at the rendered result afterwards.
Use the first for a one-off job. Use the second when a folder holds a few dozen icons. Use the third when the project keeps changing, and let the tooling remember it for you. None of these touch your PNG or JPG exports, which is a separate job covered in /blog/compress-png-without-losing-quality.
Skip the optimizer when something else rewrites the file at runtime, since renamed ids break the lookup. The same applies to templates that users edit afterwards. Files that already went through SVGO once have maybe 10 to 20 percent left, which is not worth the risk.
Confirm the bottleneck is the SVG and not a raster asset before you spend time here; the order to check things is in /blog/image-compression-web-performance-guide.
No. There are no pixels in an SVG, so scaling stays sharp. What can change is geometry: rounding coordinates moves edges by less than a pixel, and on curve-dense artwork that shift is occasionally visible.
Files exported straight from a design tool usually drop 40 to 70 percent, because editor metadata and six-decimal coordinates make up so much of them. A file that has already been processed has maybe 10 to 20 percent left.
Not the way you can with a photo. Raster files let you walk a quality slider toward a target; an SVG only has discrete chunks of redundancy to remove, and below a certain floor there is nothing left. A hard size cap means simplifying paths or dropping anchors, which is a design change rather than compression.
Defaults lean conservative and most icons come through fine. The cases that break are files with filters or masks, ids referenced from outside CSS or JS, and files that depend on sizing information beyond the viewBox. Back those up before you run it.