Free online SVG optimizer
An SVG optimizer for the half of the file that draws nothing.
A typical export from Figma, Illustrator, Inkscape or Sketch is mostly editor bookkeeping: private namespaces, nested groups that wrap one child, coordinates carried to fourteen decimal places. None of it reaches a pixel. All of it ships to every visitor.
Free and unmetered · no account · nothing uploaded, so it works offline
runs in your browser · nothing is uploaded
what leaves a typical export
xmlns:sodipodi, xmlns:inkscapenamespaces<metadata>…</metadata>authoring block<g><g><g>nesting with one childd="M 10.00000000 5.5000"unused precision\nindentation between tags
- before
- 42.6 KB
- after
- 18.9 KB
- saved
- −55%
Illustrative figures from a design-tool export. Your file reports its own before and after.
Four steps
How to optimize an SVG file.
There is no upload and no account. Step three is the one worth slowing down for.
- 01
Drop in the file
Or paste the markup. Nothing uploads — the file is read by the tab it is dropped into, which is why this works offline.
- 02
Pick a level
Conservative for files you will reopen in a design tool, balanced for anything you are shipping, aggressive for small icons at a fixed size.
- 03
Read the two numbers
Before and after, in bytes. That comparison is the point: it tells you whether a harder setting is buying you anything worth the risk.
- 04
Copy or download
Take the markup straight to a component, or download the .svg. Then serve it gzipped, which is the larger saving of the two.
If you want this inside a build pipeline rather than in a tab, SVGO on npm is the tool for that and has been for a decade. This one exists for the times you have a file, a browser and no wish to install anything.
What it does
Five passes, and what each one refuses to touch.
A minifier that quietly removes your accessible names is not saving you anything. Each pass below is paired with the thing it deliberately leaves alone.
- 01
Comments and authoring metadata
Editor comments, <metadata> blocks and generator signatures are removed. Nothing renders them; they exist only to tell you which application saved the file.
Left alone
A <title> element stays at every level — it is the accessible name, not decoration.
- 02
Per-element attribute clean-up
Editor-private namespaces (the sodipodi:, inkscape: and adobe: families), empty attributes and values identical to the SVG default are dropped from every node.
Left alone
Anything a renderer or a screen reader reads is preserved untouched.
- 03
Numeric precision
Coordinates are rounded to the precision the curve actually needs, then written in their shortest legal form — 0.5 becomes .5, and the redundant spaces around command letters and minus signs go away.
Left alone
Precision is driven by the level you choose, so you decide how aggressive this is.
- 04
Group structure
Groups that only wrap another group are unwrapped, and groups that draw nothing at all are deleted. Design tools generate these by the dozen; browsers still have to walk every one of them.
Left alone
A group carrying a transform, an ID or a style is left exactly where it is.
- 05
Whitespace between tags
Indentation and line breaks between elements collapse away. On a file with hundreds of nodes this alone is often a fifth of the bytes.
Left alone
Files containing text are left alone here — the gap between two tspans is a rendered space, not formatting.
Choosing a level
One slider, three honest zones.
High decimal precision retained. Structural clean-up only: metadata, namespaces, dead groups.
Working files you will reopen in a design tool, and anything with fine curvature you are still editing.
Precision trimmed to a few decimals. Most of the saving, with no visible change at any realistic display size.
The default for shipping. Icons, illustrations, anything embedded in a page or a component.
Precision cut hard. Very large curves can show faint faceting if you zoom deep into them.
Small icons that render at a fixed size, and sprite sheets where the byte count is the whole point.
Why it matters
Bytes are the small half of the problem.
Every node is a DOM node
An inline SVG with 900 paths adds 900 elements to the document. Layout, paint and every subsequent style recalculation walk all of them.
Diffs become reviewable
Trimmed precision means re-exporting the same drawing produces the same string. Without it, every export is a whole-file diff.
Inlining becomes viable
Under a few kilobytes, an icon can live in the HTML and cost no request at all. Above that, you are better off with a sprite.
Design tools are not build tools
Illustrator and Figma optimise for reopening the file, not for serving it. Something has to do the other job.
Questions
Optimising SVG, answered.
Including the two people ask most: does anything get uploaded, and how does this relate to SVGO.
- How do I optimize an SVG file?
- Paste the markup or drop the file in, pick a level, and read the before-and-after byte count. There is no upload step and nothing to install — the parse and re-serialise both happen in this tab, so the whole thing takes about as long as it takes to open the file.
- Does my file get uploaded anywhere?
- No. Optimisation is parsing and re-serialising, and both happen in your browser tab. The file is never sent to a server, which also means the tool works with the network off.
- Is it free?
- Yes, and unmetered. Optimising costs no credits — credits exist only for generating new artwork. There is no account needed and no file-count limit.
- Is this the same as SVGO?
- Not the same code, and worth being straight about. SVGO is the reference optimiser and the thing most online cleaners are a front end for — if you want its exact plugin set, use it directly or through its CLI. This runs a structural pass of its own, written to work without a build step and without leaving the tab, and it deliberately stops short of the transforms that can alter rendering.
- What exactly does it remove?
- Editor bookkeeping first: inkscape, sodipodi, adobe and illustrator namespaces and the attributes that needed them, metadata elements, comments and doctype declarations. Then structural waste: groups that wrap a single child, attributes already equal to the SVG default, and whitespace between elements. Then precision, if you ask for it.
- Does it clean up Figma, Illustrator and Inkscape exports?
- Those are the files it was written for. Each of those tools writes its own private attributes into the markup so it can reopen the file later, and none of it reaches a pixel in a browser — an Inkscape export in particular can carry more editor state than drawing.
- Will optimisation change how my graphic looks?
- Below about level 70, not in any way you can see. Above that the precision cut can introduce faint faceting on very large smooth curves. The before-and-after byte count is shown so you can judge whether the saving is worth it.
- Does it break accessibility?
- No. Title elements, ARIA attributes and roles are preserved at every level, precisely because they are the parts a screen reader depends on.
- How much smaller do files get?
- It depends entirely on what produced the file, so treat any single percentage with suspicion. Exports from a desktop design tool routinely lose half their weight to metadata and nesting alone. A file that was already generated clean here has much less to give up, and that is the correct outcome rather than a disappointing one.
- Should I gzip as well?
- Yes, and it is the bigger win of the two. SVG is text, so it compresses hard over the wire — serve it with gzip or brotli and a minified file gets smaller again. Optimising first still matters, because the bytes you removed are bytes the compressor never has to think about.
- Is there a command line version?
- Not of this one. If you want optimisation inside a build pipeline rather than in a tab, SVGO on npm is the right tool for that job and has been for a decade.
- Can I optimise a file I did not generate here?
- Yes. Any .svg up to 5 MB, from any source.
Drop in an SVG and see the number.
Free, unmetered, and the file never leaves your browser.