SVG Optimizer
Shrink SVG file size by removing redundant attributes, comments, and metadata
How to SVG Optimizer Online
Optimize SVG file size by removing redundant attributes, comments, and editor metadata — losslessly.
- Paste an SVG document into the input box, or use the 'Or upload a .svg file' link to load one from disk.
- Click Optimize. The first click lazy-loads the ~200 KB svgo library; subsequent clicks are instant.
- Compare the source and optimized previews side by side — visually, they should be identical.
- Read the byte counts and savings percentage. Inkscape and Illustrator exports typically shrink 70–90%.
- Click Copy to put the optimized markup on your clipboard, or Download to save it as `optimized.svg`.
About SVG Optimizer
Most SVG you encounter in the wild is bloated. The reason isn't the format — SVG itself is compact — it's the editors that produce it. Inkscape adds about 1 KB of `<sodipodi:>` and `<inkscape:>` namespace declarations and editor-specific attributes to every file. Adobe Illustrator adds Illustrator-specific tags, comments noting which Illustrator version saved the file, and unused gradient definitions. Sketch adds its own bookkeeping. Online icon libraries often ship every icon with the same five copies of the same metadata block. None of this is required to *render* the SVG — your browser, your design system, your icon font generator all ignore it. Stripping it shrinks the file by 30% to 90% with zero visual change.
The optimizer here wraps **svgo**, the de-facto standard SVG optimizer. svgo started as a Node CLI tool and has been the engine inside every major SVG cleanup workflow for a decade — Webpack's svg-loader uses it, every icon-generator tool uses it, Vite's SVG plugin uses it, design-token compilers use it. The defaults are conservative and *lossless*: the optimized SVG renders identically to the source, just smaller. The 30+ plugins svgo enables by default remove categories of markup that have no visual impact:
- **Editor metadata** (Inkscape, Illustrator, Sketch namespaces and bookkeeping). - **Comments** and **`<title>`** / **`<desc>`** elements (the latter unless they're being used for accessibility). - **Default attribute values** (an attribute set to its CSS-spec default is the same as omitting it). - **Redundant wrapping groups** (`<g><path .../></g>` becomes `<path .../>`). - **Unused IDs**, **unused symbols**, **empty groups**. - **Numeric precision** — coordinates trimmed from 8 decimal places to 3 (still sub-pixel accurate). - **Equivalent path commands** (multiple Lines compressed into one PolyLine; absolute-vs-relative coordinates chosen by which produces shorter output).
This tool ships svgo's default plugin set plus two extra strippers that are useful for web SVG: `removeXMLNS` drops the `xmlns="http://www.w3.org/2000/svg"` declaration (HTML5 inline SVG doesn't need it — only standalone .svg files do, and the tool keeps it for downloaded files implicitly through the browser's SVG MIME type), and `removeDimensions` drops fixed `width` and `height` in favor of `viewBox`-only sizing, which makes the SVG more flexible to style from CSS. The download path preserves the standard XML declaration.
The **side-by-side preview** is the design feature that makes the tool actually useful. Optimizers that produce a textual diff without a visual comparison force you to trust them; this one lets you eyeball the result against the source. If anything looks off — and it almost never will — you know immediately. The previews render through `<img src="data:image/svg+xml,...">` rather than inlining the SVG into the page, which is a small security consideration: SVG can contain `<script>` elements and `javascript:` hrefs that execute when inlined into HTML, but rendering via `<img>` always disables script execution per the HTML spec.
A practical tip: for an icon system, the savings compound. If you ship 100 icons through svgo and each saves 500 bytes on average, that's a 50 KB win for free — gzipped, probably 10 KB, still meaningful for first-paint metrics. For a site that uses SVG sparingly, the per-icon savings matter less than the cumulative simplification of your markup (fewer namespace declarations means less mental overhead when you look at the file).
Everything runs in your browser. svgo is ~200 KB compressed and is lazy-loaded on the first Optimize click, so pages that don't use this tool don't pay for the library. No network requests during optimization. SVG content — including any private icons, brand assets, or unreleased designs — stays in your tab.
Related Tools
Frequently Asked Questions
What does svgo actually remove?
Stuff that vector renderers don't need but design tools embed by default: editor metadata (Inkscape's `inkscape:` namespace, Illustrator's `i:` namespace, Sketch's bookkeeping), comments, default attribute values, XML namespace declarations the rendering layer ignores, redundant `g` groups that wrap a single child, identical sibling `path` elements, and a long list of other low-value markup. The geometric shapes themselves — paths, fills, strokes — are preserved exactly. Typical savings range from 30% (clean hand-written SVG) to 90%+ (Inkscape exports with embedded metadata).
Will the optimized SVG render the same?
Yes, for any reasonable SVG. svgo's default plugin set is specifically designed to be lossless — visual fidelity is preserved. The two previews (source vs. optimized) let you sanity-check this side by side. If you notice any visual difference, it's almost always because the source SVG was depending on a non-standard renderer behavior (like Illustrator-specific attributes) that doesn't render in standard SVG viewers anyway.
Why does my SVG get marginally larger sometimes?
Two reasons. **Tiny SVGs** (under a few hundred bytes) sometimes grow slightly because svgo adds a small amount of attribute reformatting that's not paid back at small file sizes. **Already-optimized SVGs** can't shrink further; if you run an SVG through svgo twice, the second pass is a no-op or a tiny increase from re-serialization quirks. If your output is larger than the input, the source was already lean and there's nothing useful to remove.
Why does the preview use `<img src="data:...">` instead of inlining the SVG?
Security. SVG can contain `<script>` elements that execute when the SVG is inlined into HTML, and `<image href="javascript:...">` patterns that work the same way. When SVG renders inside an `<img>` tag (or as a CSS `background-image`), browsers explicitly do NOT execute scripts — this is mandated by the HTML/SVG specs and enforced consistently in every modern browser. Using `<img>` with a `data:` URL lets you preview pasted untrusted SVG safely.
Does it remove `viewBox` or `width`/`height`?
It removes `width` and `height` when `viewBox` is present (you can size the SVG from CSS instead, which is more flexible). It preserves `viewBox` — that's the part that defines the coordinate system. If your usage depends on the SVG having intrinsic dimensions, add `width` and `height` back in your CSS, or remove the `removeDimensions` plugin from the config (the tool ships with it enabled because it's the right call for 90% of web SVGs).
What about preserving comments or specific IDs?
svgo's default config strips both. For specific IDs you need to reference from CSS or JS, the workaround is to add a special prefix svgo's `cleanupIds` plugin knows to preserve, or skip the optimization for that SVG. This tool ships with the standard `preset-default` config; for custom needs, install svgo locally (`npm install svgo`) and write a `svgo.config.js`.
Is anything sent to a server?
No. The svgo library (~200 KB compressed) is bundled with the page and runs entirely in your browser. SVG content stays in your tab. The library lazy-loads on the first Optimize click so the rest of the site is not penalized.