SVG Optimizer
Strip editor cruft and shrink SVG file size — entirely in your browser
Drag & drop an .svg file, or paste SVG markup below
About this tool
The SVG Optimizer strips the invisible bloat that design tools like Illustrator, Figma, and Inkscape add to exported SVG files — comments, metadata, editor-specific namespaces, empty groups, and excessive coordinate precision — often shrinking file size by 50% or more without any visible change to the image. Exported SVGs frequently carry editor cruft that serves the editor, not the browser: Inkscape and Sodipodi namespaces recording tool state, XML comments, <title> and <desc> elements duplicating alt text, and path coordinates specified to 6+ decimal places when 2 is visually indistinguishable.
When to use it
- →Shrinking icon sets exported from Figma or Illustrator before adding them to a project
- →Cleaning up SVGs before inlining them directly in HTML or JSX, where every byte is duplicated per use
- →Removing Inkscape/Sodipodi editor metadata that leaks tool version and workspace info
- →Reducing SVG file size for faster page loads on image-heavy sites
Tips
- ◆2 decimal places of coordinate precision is visually indistinguishable from the original in almost all cases — try 1 for icons if you want to push size down further.
- ◆Removing width/height (keeping only viewBox) makes an SVG scale cleanly to any container size via CSS — useful for icon components.
- ◆Always spot-check the visual preview after optimizing — aggressive precision rounding can occasionally distort very small or highly detailed paths.
Frequently asked questions
Will optimizing change how my SVG looks?
The default settings (2 decimal places, removing comments/metadata/empty groups) are chosen to be visually lossless for the vast majority of SVGs. Reducing precision further, or removing width/height on an SVG that relies on them for layout, can occasionally cause visible differences — always check the before/after preview.
Why is my exported SVG so much larger than it needs to be?
Design tools optimize for editability, not file size — they preserve full undo history context, layer names, tool-specific metadata (Inkscape/Sodipodi namespaces), and high-precision coordinates from every anchor point adjustment. None of that is needed for the SVG to render correctly in a browser.
Is this the same as running SVGO?
It targets the same class of bloat — comments, metadata, editor namespaces, empty elements, coordinate precision — using a lighter, browser-native implementation rather than the full SVGO plugin pipeline. For typical icon and illustration exports, the size reduction is comparable; SVGO's more advanced optimizations (path merging, attribute-to-CSS conversion) aren't included.
Can I optimize an SVG that has embedded raster images or fonts?
Yes, but the savings will be smaller in percentage terms — this tool optimizes SVG markup (paths, groups, metadata), not embedded base64-encoded images or font data, which typically account for most of the file size when present.