SVG Optimizer — Clean & Minify SVG Markup
Paste an SVG and get back a smaller one — comments, metadata and stray whitespace gone, coordinates rounded, the picture unchanged.
—
What this tool does
It makes an SVG file smaller by removing what a renderer ignores. Exported SVGs carry a lot of
weight nothing draws: XML comments, a DOCTYPE, editor-specific metadata, descriptive
<title> and <desc> elements, newlines and indentation between
tags, and coordinates given to six decimal places. Stripping those can halve a file while the
picture stays pixel-for-pixel the same.
What is removed, and why it is safe
| Removed | Why it does not change the image |
|---|---|
| Comments & XML prolog | Never rendered. |
| Metadata / editor blocks | Editing hints only. |
| Whitespace between tags | SVG is structure, not a text layout. |
| Extra decimal places | Below display precision — 2dp is far finer than any screen. |
Why size matters for SVG
An SVG is often inlined into HTML, so every byte is downloaded on every page view — unlike a raster image it cannot be compressed as well by gzip and it sits in the critical path of the markup. A logo that is 40 KB of exported cruft instead of 8 KB is paid for on every load. Optimising once, at author time, is a permanent saving that costs nothing at run time.
Where this tool stops
It does the safe structural pass and leaves the geometry alone. It will not rewrite path commands, merge redundant groups or convert shapes to paths — those can change the rendering if done wrong, and they need a full SVG parser. For a file that must not change visually, this is the conservative choice; for maximum compression where you can eyeball the result, a heavier optimiser is the tool.
Frequently asked questions
What does an SVG optimizer remove?
Everything the renderer does not need: XML comments, the XML declaration, the DOCTYPE, editor metadata such as Inkscape or Illustrator blocks, <title> and <desc>, the whitespace between tags, and the long decimal places on coordinates. What is left draws the same picture in fewer bytes.
Will the image look different?
No. Geometry, colours and structure are untouched; the only numeric change is rounding coordinates to a fixed number of decimals (two by default), which is far below what any screen or printer can show. The saving comes from removed bytes, not altered content.
How much smaller will my SVG get?
It depends on the source. A file exported from a design tool with metadata and six-decimal coordinates can shrink by more than half; a hand-written, already-tidy SVG may only drop a few percent. The tool reports the exact before and after so you can see.
Why not use SVGO?
SVGO does more — it rewrites path data, merges styles and can restructure the whole document — at the cost of a large dependency and, occasionally, a visual change that needs checking. This tool does the safe structural pass in the browser with no dependency and no risk to the geometry.
Is my SVG uploaded?
No. The optimisation is a text transformation done in your browser; the file never leaves the page. That matters when the SVG is a client logo or an unreleased asset.
What if I paste something that is not SVG?
The tool says so rather than producing a corrupt file: it checks for an <svg> element first and refuses anything else. Paste the markup (not a file path) to optimise it.
Go deeper
Longer explanations of the problems this tool solves:
Sources
- SVG 2 — Scalable Vector Graphics (W3C).
- SVGO — the reference optimiser this tool deliberately replaces with a dependency-free subset.
Everything runs in your browser — nothing you type is uploaded.