🧹 SVG Optimizer

SVGO in your browser: paste an SVG, get it minified with safe defaults, see the rendered result and the exact bytes saved.

Input SVG

Optimised output

The optimised SVG renders here so you can see nothing broke.

About the SVG Optimizer

Design tools export SVGs meant for re-editing, not shipping: editor metadata, layer names, hidden groups, seven-decimal coordinates. SVGO — the standard optimiser the whole ecosystem builds on — strips all of it while preserving how the image renders. This page runs SVGO entirely in your browser, loaded on demand, with a rendered before-you-commit preview.

The defaults are deliberately safer than SVGO's own: viewBox is kept so CSS scaling keeps working, and IDs are preserved because external stylesheets and scripts may reference them. Both toggles are there when you know your file better.

How to use it

Paste SVG markup or drop a .svg file anywhere on the panes.
Read the verdict bar — exact bytes in, bytes out, percentage saved.
Check the rendered preview; if something visual broke, flip Pretty-print on and diff the two panes.
Copy or download the optimised file.

Frequently Asked Questions

What does SVGO actually remove?

Editor metadata (Inkscape, Illustrator and Figma all embed their own), comments, hidden elements, default-value attributes, needless precision in path coordinates, and empty groups. For hand-drawn or design-tool exports, 40–70% savings are normal — vector editors optimise for editing, not for shipping.

Is optimisation safe? Will my SVG look different?

The default preset is SVGO's curated safe set, and this tool keeps viewBox (which the raw preset removes) so CSS scaling keeps working. The one genuinely unsafe toggle — cleaning up IDs — is off by default because external CSS or JS may reference them. Compare the preview panes before downloading; that is what they are for.

Why keep the viewBox?

Without a viewBox, an SVG has no intrinsic coordinate system to scale from — width/height in CSS stops working proportionally and the image renders at a fixed size. SVGO removes it by default for maximum byte savings; this tool overrides that because a broken responsive logo costs more than the ~20 bytes.

Does my SVG get uploaded for optimisation?

No — SVGO runs as JavaScript in your browser (it is loaded on demand the first time you optimise). Your file, which for many teams is unreleased brand or product artwork, never leaves the page.

Why is the preview sanitised?

SVG is a full XML format that can carry <script> elements and event handlers — rendering an untrusted one raw would execute whatever it carries. The preview passes through DOMPurify's SVG profile first. The optimised OUTPUT text is untouched; sanitisation applies only to what this page renders.

Should I optimise SVGs at build time instead?

Yes, if you have a build: vite-plugin-svgo or SVGO's CLI make it automatic. This page is for everything outside the pipeline — a logo somebody emailed, an icon from a designer's export, a one-off graphic — where you want the bytes and a diff you can eyeball right now.

SVG optimisation with SVGO: what it removes and what to keep

SVGs exported from design tools are written for re-editing, not shipping. Illustrator, Figma, Sketch and Inkscape all embed their own metadata — editor namespaces, layer names, hidden elements, empty groups, coordinates to seven decimal places — and none of it affects a single rendered pixel. Cutting a hand-exported SVG's size by half is routine; 70% is common.

SVGO is the ecosystem's standard optimiser, the engine inside everything from webpack loaders to design-tool export plugins. Braxik's SVG Optimizer runs SVGO in your browser: paste markup or drop a .svg file, read the exact byte verdict, compare the rendered result against your expectation, and copy or download the output.

The defaults here are deliberately safer than SVGO's own history. The viewBox is kept — its removal silently breaks CSS scaling — and IDs are preserved, because external stylesheets and scripts reference them and no optimiser can see that from inside the file. Both protections are toggles when you know your file better.

The rendered preview is sanitised with DOMPurify before display, because SVG is a full XML application that can carry scripts — and an optimiser page that executed whatever you pasted into it would be a cross-site-scripting exercise, not a tool. The output text itself is untouched.

How it works

SVGO (~100 KB) is loaded on demand the first time you optimise — it never rides in the main bundle. Your markup runs through SVGO's preset-default plugin set, the curated safe list the SVGO project maintains, with this tool's protective overrides applied.

Multipass (on by default) re-runs the plugin pipeline until a pass produces no further savings — removals cascade, and a group emptied by one pass is removable by the next. Pretty-print re-indents the output for files headed into version control rather than production.

Byte counts are computed on the UTF-8 encoding of input and output — the number that actually goes over the wire — and the verdict is reported honestly, including the rare case where an already-optimised file cannot be improved.

Common uses

Optimise a logo or icon a designer exported before committing it to the repository.
Clean the editor metadata out of an SVG before publishing it — layer names and editor namespaces can leak internal naming.
Shrink inline SVGs used in React/Vue components, where every byte ships inside your JavaScript bundle.
Minify SVG illustrations for a marketing page where they are the largest assets.
Pretty-print a minified SVG to understand or hand-edit its structure, then re-minify.
Verify what an optimiser would do to a file BEFORE wiring SVGO into a build pipeline with the same preset.
Sanity-check a suspicious SVG's rendered appearance in a sanitised preview rather than opening it raw in a browser tab.

Before you rely on the result

Compare the rendered preview against the original before shipping — the preset is safe, but 'safe' is a statistical claim and your file is a specific one.
Keep the viewBox unless the SVG is used at a truly fixed size; without it, CSS scaling stops working proportionally.
Leave ID cleanup off when any external CSS, JS or <use> references the file's ids — the optimiser cannot see external references.
For SVGs with text elements, check the text still renders — font and kerning attributes are a classic casualty of aggressive optimisation.
If the output is barely smaller, the file was already optimised; re-running SVGO on its own output is a no-op by design (that is what multipass automates).
Keep the original file in version control history — optimisation is easy to redo and impossible to undo without the source.
For a build pipeline, replicate these settings in svgo.config.js so hand-optimised and build-optimised files match.