✂️ SVG Optimizer / Minifier
Remove metadata, comments, whitespace, editor tags from SVG and round decimals to slash file size. Output as raw / CSS / HTML / JSX / Vue.
Preview
🔗 Related Tools
📖 Where people get stuck
Strips comments, metadata and editor-specific attributes from an SVG, collapses whitespace and rounds decimals to cut the size, with output as a CSS data URI, an HTML img tag, JSX or Vue. Everything runs in the browser. Some things are safe to remove and some break the drawing — id in particular may be referenced by a <use>, a clipPath or a gradient, and so cannot be removed mechanically.
| Case | What happens | What to do |
|---|---|---|
| The drawing broke after optimising | There are essentially two causes. One is removing an id: <use xlink:href="#icon">, clip-path="url(#mask1)" and fill="url(#grad1)" all reference ids, and losing one makes the shape disappear or turn solid black. The other is rounding decimals too far: on a small icon or a thin stroke, rounding to one decimal place is enough to collapse coordinates and distort the shape. Both produce a smaller file that draws differently, and looking only at the numbers it appears to have worked. |
Keep decimals at two or three places — going down to one trades too much breakage risk for the bytes it saves. And always compare before and after side by side with your eyes (the preview on this page): judging by the file size figure alone is the most common failure in this task. For id, an inline SVG referenced from external CSS or JavaScript needs those ids preserved — SVGO enables cleanupIds by default too, so the same problem arises there. Placing several SVGs on one page needs the opposite care: an id must be unique within the page, so two SVGs sharing an id leave the second one referencing the first definition. |
| Removing title and desc costs you accessibility | In an SVG, <title> plays the role of alternative text — a screen reader announces it. Removing it from a decorative SVG is fine, but removing it from a meaningful icon — the contents of a button, a status indicator, a chart — leaves nothing to announce what the button does. Icon-only buttons are the dangerous case: with no text label, if <title> was the only cue, deleting it reduces the announcement to the word button. Nothing changes visually, so there is no occasion to notice. |
Decide by the role the SVG plays. Loaded through <img>, the alt attribute is the alternative text, so the <title> inside the SVG is unnecessary and can go. When it is inline and meaningful, keep the <title> and add role="img" with aria-labelledby — <svg role="img" aria-labelledby="t1"><title id="t1">Save</title>. When it is purely decorative, remove the <title> and add aria-hidden="true": that is the equivalent of an empty alt, and explicitly saying there is nothing to announce is better than simply deleting it. The test is whether the meaning changes if the graphic were absent. |
| Turning it into a data URI made it bigger | Base64 always adds about 33 percent, so optimising an SVG down by 30 percent and then Base64 encoding it lands you back at roughly the original size. Worse, a Base64 string barely compresses under gzip: SVG is text and would normally compress by around 70 percent, and encoding it as Base64 throws that away. Believing that a data URI removes a request and therefore speeds things up, while actually nearly doubling the bytes transferred, is a common reversal in this workflow. | If you are making a data URI from an SVG, percent-encode it rather than Base64 it — data:image/svg+xml,%3Csvg.... SVG is text, so percent-encoding is smaller than Base64 and still compresses under gzip. Only #, % and " must be escaped; the rest can sit there as they are, though escaping < and > as well is safer. A data URI only wins for icons of a few kilobytes or less; beyond that, an ordinary <img> or an inline SVG is faster because it can be cached. The data URI is a technique for keeping everything inside a stylesheet, not a speed optimisation. |
The largest saving comes from the export settings, not from a tool. Illustrator and Figma export SVG with a great deal of editor metadata, layer names and redundant groups by default, but choosing an option such as minimal or the SVG 1.1 profile means none of it is written in the first place — and not producing it is more reliable and quicker than stripping it afterwards. If you use many icons, combine them into an SVG sprite rather than optimising each one: you win on both request count and total bytes. Finally, security — never inline an SVG you received from outside. SVG is XML that can contain <script> and an onload attribute, so inlining it is XSS. To display an SVG a user uploaded, load it through <img src="...">, where scripts do not execute. If you must handle it inline, sanitise it with the SVG profile of DOMPurify without exception.
📖 How to Use
-
1
Paste SVG or open a filePaste SVG code into the left textarea or click Open to load an SVG file. Use the Sample button to try a demo SVG.
-
2
Select optimization optionsToggle checkboxes such as remove comments, strip metadata, strip editor attributes, and collapse whitespace. Reducing decimal precision can cut size further.
-
3
Copy output or choose a formatThe optimized SVG appears on the right. Switch the format dropdown to output as CSS background-image data URI, HTML img, JSX, or Vue.
❓ Frequently Asked Questions
How much size reduction can I expect?
Does removing title/desc affect accessibility?
Can I use the JSX output directly in React?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.