Skip to content

Optimize SVG

Clean and compress SVG files using SVGO entirely in your browser. Reduce file sizes for faster web loading without any loss of quality.

SVG Optimizer

Reduce the file size of your SVGs by safely removing unnecessary data, metadata, and minifying paths, all in your browser.

What an SVG is carrying that you did not ask for

An SVG exported from Illustrator, Figma or Inkscape is an XML document, and design tools are generous about what they leave in it. A typical export carries editor-specific metadata blocks, the layer names you used while working, comments, empty groups left over from an earlier arrangement, elements that were hidden when you exported, unreferenced clip paths, and default attributes that restate values the renderer would have assumed anyway.

Then there is coordinate precision. A path built by dragging handles gets written out with as many decimal places as the editor tracked internally, so a curve is described to a nanometre when it will be drawn on a screen at 24 pixels wide. That precision is often the single largest thing in the file, and rounding it costs nothing visible.

What that is worth, on real files

Percentages quoted for this kind of tool are close to meaningless without knowing the source, because the saving is almost entirely a function of how untidy the export was. These are this site’s own assets, run through the same optimiser on this page:

  • The DuckConvert logo lockup: 13,259 → 4,443 bytes, a 66% reduction.
  • A small diagram: 1,442 → 1,207 bytes, 16%.
  • The duck mark: 1,584 → 1,271 bytes, 20%.

The lockup saved four times what the diagram did, and the difference is not the optimiser — it is that the lockup came out of a design tool with the editor’s furniture still attached, while the other two had already been through this once. An icon written by hand may lose almost nothing. If a file barely shrinks, it was probably already clean.

Multipass, and why one pass is not enough

Optimisation runs repeatedly rather than once, because the cleanups feed each other. Removing a hidden element can leave its parent group empty; removing that empty group can strip the last reference to a gradient definition; removing the gradient can make a further attribute redundant. Each pass finds work the previous one created, and the process runs until the file stops getting smaller.

An SVG is an executable document

This is the part that catches people out. SVG is not a picture format in the way PNG is. It can contain script elements, event handler attributes, and links with javascript URLs, and those run when the file is opened directly in a browser or inlined into a page. An SVG downloaded from the internet and then hosted on your own domain is, in that situation, code running in your origin.

Standard optimisation does not remove any of that, because stripping behaviour is not a size question. This tool removes it anyway, on the grounds that a file coming out of an image optimiser should be an image. If you are cleaning up assets before putting them on a site, that matters more than the bytes saved.

When to check the result

Optimisation is conservative but not risk-free, and the failure mode worth knowing about is specific rather than general.

An id that nothing inside the file refers to is removed. A class is kept. That asymmetry is easy to trip over. A rectangle written as <rect id="spinner" class="anim"> comes back carrying the class and nothing else, because the optimiser can see that no gradient, clip path or use element inside the document points at that id — it cannot see the stylesheet or the script elsewhere on your page that does. If you animate or address parts of an SVG from outside it, target them by class, or check the ids survived.

Two things people expect to break do not. viewBox is preserved, including on files that also carry matching width and height — older advice to disable that cleanup by hand is out of date, and losing it would break scaling entirely. And the xmlns declaration stays, so the result still works as a standalone file rather than only when inlined.

What does change silently is shape and precision. Coordinates are rounded to three decimal places and paths are rewritten into a shorter relative form, so M1.2345678901 2.3456789012 becomes m1.235 2.346, and a <rect> becomes a <path>. Both are visually identical at any normal size and both make the file unrecognisable if you were planning to hand-edit it afterwards. Rounding can shift a hairline stroke by a fraction of a pixel — invisible on an illustration, occasionally noticeable on a precisely aligned icon at very small sizes. Comparing before and after at the size you actually ship takes a moment and settles it.

Optimize SVG FAQ

What does optimizing an SVG actually remove?

It runs SVGO's default cleanup, stripping editor metadata, comments, unused definitions, and redundant precision from path coordinates, which typically shrinks an SVG exported from design tools like Illustrator or Figma significantly without changing how it renders.

Is it safe to optimize an SVG from a source I don't fully trust?

SVG is technically an executable document format: it can contain <script> tags and event handlers. On top of SVGO's normal cleanup, this tool always strips scripts and event handlers from the output, so the optimized file can't carry embedded JavaScript even if the original did.

Will optimization change how my SVG looks?

No. The default cleanup is lossless for rendering. It removes data that doesn't affect the visual output (metadata, comments, excess coordinate precision), not visible content.