SO
SVG Optimizer
Clean and minify pasted SVG markup — strip comments, editor metadata and excess precision, with a before/after preview and byte-size reduction.
More Image Tools Tools
bytes → bytes
(% smaller)
How to Use SVG Optimizer
Paste raw SVG markup, or upload an .svg file, then click Optimize. The tool strips comments, editor-only metadata and excess numeric precision, and collapses unnecessary whitespace, then shows you the original and optimized file size, the percentage saved, and a live side-by-side rendered preview of both versions so you can visually confirm nothing changed. Download the cleaned result, or copy it straight to your clipboard.
About SVG Optimizer
SVG files exported from design tools like Illustrator or Inkscape are frequently far larger than they need to be — not because the actual artwork is complex, but because the exporting application leaves behind a trail of information that only mattered to the editor that created the file: comments describing layers, `<metadata>` blocks with authoring history, editor-specific namespaced attributes like `inkscape:label` or `sodipodi:nodetypes` that only Inkscape itself ever reads, and coordinate values expressed to eight or more decimal places of precision that no screen can actually render a visible difference for. None of that content affects how the image looks when rendered — it exists purely as authoring convenience for the original design tool — so stripping it is one of the few genuinely "free" size reductions available: the visual output stays identical, but the file gets meaningfully smaller and faster to load.
This is a real, useful implementation of that idea, deliberately built as a simple, safe, transparent subset — not an attempt to reimplement a full tool like SVGO, which additionally does much more aggressive and structurally invasive optimizations (path data re-encoding, shape-to-path conversion, merging paths, removing "invisible" elements by interpreting complex style cascades, and dozens of other transforms) that carry real risk of subtly changing how an SVG renders if applied incorrectly. What this tool does instead is a small, clearly-documented set of purely textual, structurally conservative cleanups: strip comments, strip `<metadata>` blocks and Inkscape/Sodipodi-specific attributes (while deliberately *keeping* `<title>` and `<desc>`, since those matter for accessibility and tooltips — not everything with a tag name that sounds like metadata gets removed indiscriminately), collapse whitespace that exists purely for human-readable indentation, and cap excessive numeric precision to two decimal places.
Two safety nets make this trustworthy to actually use rather than just a black box. First, your input is validated *before* anything is touched: the pasted or uploaded markup is parsed with the browser's own `DOMParser`, and if it isn't well-formed XML, or doesn't have an `<svg>` root element, you get a clear error immediately rather than a mangled attempt at "optimizing" something that was never valid in the first place. Second — and this is the detail that matters most for trusting the *output*, not just the input — after the cleanup regex transformations run, the tool re-parses its *own result* with that same `DOMParser` check. If the regex-based whitespace collapsing or attribute stripping ever accidentally corrupted the markup into something no longer valid (a risk inherent to any text-based, rather than fully DOM-based, transformation), that failure is caught and shown as an explicit error with no download offered, rather than silently handing you a broken file that only reveals itself as broken once you try to use it somewhere else.
Details & Tips
The optimization pipeline runs four passes, in this order, directly on the SVG text: (a) strip every XML/HTML comment (`<!-- ... -->`); (b) strip `<metadata>...</metadata>` blocks entirely, along with any attribute whose name starts with `inkscape:` or `sodipodi:` (and their `xmlns:inkscape` / `xmlns:sodipodi` namespace declarations) — `<title>` and `<desc>` elements are deliberately kept, since they carry real accessibility and tooltip value, unlike purely editor-internal metadata; (c) round any numeric attribute value that already carries three or more decimal digits down to exactly two (so `12.345678` becomes `12.35`, while an already-short `12.5` is left untouched rather than needlessly padded to `12.50`) across the coordinate-bearing attributes `d`, `x`, `y`, `width`, `height`, `cx`, `cy`, `r`, `rx`, `ry`, `x1`, `y1`, `x2`, `y2`, `points`, `viewBox` and `stroke-width`; (d) collapse whitespace runs that sit purely between two tags (typical pretty-printed indentation) down to nothing.
That last step is worth walking through carefully, because getting it wrong would be a real correctness bug: the collapsing regex only ever matches a run of whitespace characters that sits between a `>` and the very next `<`, with *nothing else* in between. Given `<svg>\n <rect .../>\n <text>Hello World</text>\n</svg>`, the newline-and-indentation whitespace between `<svg>` and `<rect` is pure whitespace with nothing else present, so it collapses away cleanly. But the space between "Hello" and "World" inside `<text>Hello World</text>` is never touched, because it doesn't sit between a `>` and a `<` at all — it sits between two ordinary letters, entirely inside the text node's own content, which the collapsing pattern never even looks at. The one gap that *does* sit between tags here — right after `<text>` and right before `</text>`'s closing bracket, if the source had any surrounding whitespace there — would only collapse if that entire gap were whitespace; since "Hello World" occupies it, the pattern can't match across real content, and the visually meaningful space survives untouched.
Size reduction is measured with the browser's own `Blob` size in bytes (which correctly accounts for multi-byte UTF-8 characters, unlike a plain string-length count), for both the original and optimized text, and shown as a percentage saved. The live before/after preview renders both versions by inserting the markup into two separate preview containers — a deliberate, narrowly-scoped exception to this codebase's usual "never render user input via innerHTML" rule, made safe here specifically because it is the *same* user viewing their *own* just-pasted markup back in their *own* browser tab: no other user, page or origin is ever involved, so no privilege boundary is crossed, and rendering it as real SVG (rather than escaped text) is the entire point of a visual before/after comparison.
Worked example: a typical Inkscape export might include a leading XML comment block, a 200-byte `<metadata>` block with RDF authoring data, a dozen `inkscape:` and `sodipodi:` attributes scattered across path elements, path coordinates specified to 10+ decimal places, and two-space pretty-printed indentation throughout — a combination that routinely adds 30-60% to the file's size without changing a single visible pixel. Running that same file through this tool typically shows a meaningful percentage reduction while the before/after preview panels render pixel-identically, which is exactly the point: smaller file, same picture.
Frequently Asked Questions
Is this the same as running SVGO?
No. This is a small, hand-rolled, deliberately conservative subset covering comment/metadata stripping, editor-attribute removal, whitespace collapsing and numeric precision capping — not a full reimplementation of SVGO's more aggressive, structurally invasive optimizations like path re-encoding or element merging.
Will optimizing change how my SVG looks?
It shouldn't — every step removes only content that has no visual effect (comments, editor-only metadata, excess decimal precision, pretty-print whitespace). The side-by-side before/after preview lets you visually confirm this yourself for your specific file.
Does it strip <title> and <desc> elements?
No — those are kept deliberately, since they carry real accessibility and tooltip value, unlike <metadata> blocks or Inkscape/Sodipodi-specific attributes, which exist purely for the original editing application and are safe to remove.
Will whitespace inside my <text> elements get collapsed by mistake?
No. The whitespace-collapsing step only ever matches whitespace that sits purely between a closing '>' and the next '<' with nothing else present — it never touches spaces sitting inside real text content, like the space between two words in a <text> label.
What happens if I paste something that isn't valid SVG?
It's validated with the browser's DOMParser before anything else happens — if it isn't well-formed XML or doesn't have an <svg> root element, you get a clear error immediately rather than a broken optimization attempt.
What if the optimization itself produces broken output?
The tool re-parses its own output with the same validation check used on your input. If the cleanup ever corrupted the markup, that's caught immediately and shown as an explicit error with no download offered, rather than silently handing you a broken file.
How much decimal precision does it keep in coordinates?
Only numbers that already have three or more decimal digits get rounded, and they're capped to exactly two. A short value like "12.5" is left completely untouched rather than needlessly padded.
Is my SVG markup uploaded to a server when I optimize it?
No. Parsing, cleaning and re-validating all happen with JavaScript running locally in your browser — nothing you paste or upload is transmitted, logged, or stored anywhere.
Why does the before/after preview render as an actual image instead of code?
The markup is inserted into a dedicated preview container so it renders as real SVG, which is what makes a visual before/after comparison useful. This is a deliberate, narrowly-scoped exception to this codebase's usual rule against rendering user input directly, safe here because it's the same user viewing their own pasted content in their own browser tab.
Can I upload a file instead of pasting markup?
Yes — the file upload field reads a local .svg file's text content directly into the input box, exactly as if you had pasted it, so you can optimize a file from disk without opening it in a text editor first.
How is the byte-size reduction calculated?
Both the original and optimized text are measured in actual bytes (correctly accounting for multi-byte characters), and the percentage saved is the difference between them relative to the original size.
Part of These Collections
Also Available As
svg optimizer, svg minifier, clean svg, reduce svg file size, svgo alternative, optimize svg online
Found a Problem?
Let us know if something with SVG Optimizer isn't working as expected.
Something went wrong. Please try again.
Thanks — we'll take a look.