SVG Optimizer
An SVG exported from Figma, Illustrator, or Sketch is honest XML, but it arrives padded with things a browser never renders: editor metadata, a generator comment, wrapper groups that hold a single path, coordinates carried to five decimal places, and colours written the long way. This optimizer strips all of it in one paste. You drop in the markup and get back the smallest equivalent SVG, with the original, optimized, and gzip sizes shown side by side and a live preview of both so you can confirm the shape is untouched. When a pass takes something with it — an id your stylesheet points at, a sprite nothing in the file references — it says so instead of leaving you to find out later. It is the svgo engine running entirely in your browser, so nothing you paste ever leaves the tab.
Overview
An SVG optimizer is only worth using if you can trust the output and see the gain. This one is built around both: accurate compression you can ship, next to the numbers and the preview that prove it was safe.
- 01
Tree-based optimization
The SVG is parsed into a real element tree before anything changes, so metadata, XML prologs, generator comments, empty groups, and redundant attributes go while the drawing stays identical. Colours are shortened, default values dropped, and path data rewritten more compactly — dozens of transforms, none of them a fragile find-and-replace that breaks on a gradient or a nested transform.
- 02
It tells you what it took with it
The default preset deletes every id nothing inside the file points at and renames the rest, which is right for an icon and wrong for a logo your CSS styles or a sprite whose
<use>lives in the page. Anything left pointing at nothing is listed under the output, and Keep IDs turns the whole behaviour off in one click. - 03
A precision control you can dial
Coordinates exported at five decimal places are rarely needed. Round them down to shrink path data, and use the side-by-side preview to stop the moment detail starts to blur.
- 04
Responsive-ready output
Optionally strip the width and height attributes so the SVG inherits the size of whatever box holds it, the usual choice for icons and inline illustrations that need to scale.
- 05
A size breakdown you can trust
Original, optimized, and gzip sizes update as you edit, next to the exact percentage saved. The gzip figure is the one that matches what travels over the wire.
- 06
See it before you ship it
Flip the output to Preview and the original and optimized SVG render together on a checkerboard, so a broken clip path or dropped fill is obvious before you copy the result. Each side renders as its own image, which keeps their ids from bleeding into one another and means an SVG you did not write can neither run its scripts nor fetch anything it references.
How to use
Go from a bloated editor export to a lean, production-ready SVG in a few steps, with the saving and a preview in front of you the whole time.
- 01
Paste your SVG into the input panel, or use Upload to load an .svg file straight from disk.
- 02
Choose your options. Leave Multipass on for the smallest result, turn on Keep IDs when anything outside the file addresses an id or the file is a sprite, and turn on Remove width/height when you want the icon to scale to its container.
- 03
Flip the output to Preview to confirm the optimized SVG renders exactly like the original, read anything listed under the output as worth checking, then read the size breakdown to see the gain.
- 04
Copy the optimized SVG or download it as an .svg file, then drop it into your markup, sprite sheet, or component.
Details
The details that make the output safe to ship and quick to trust.
- Built on svgo, the standard SVG optimizer that runs on a parsed tree rather than by text substitution, using the same preset that build tools default to.
- Each preview renders as an image rather than being injected into the page, so an SVG you did not write cannot run its scripts, cannot fetch anything it references, and cannot borrow the other preview’s gradients through a shared id.
- The gzip size is measured with the compression built into your browser, so the figure reflects what a real server would send.
- Optimization runs as you edit, a moment after you stop typing, so a large traced illustration never locks the editor mid-keystroke.
- A parse error is shown in place with its message, and an optimization that came back empty is called out rather than presented as a 100% saving.
- Nothing is uploaded or logged. The SVG you paste, including unreleased brand assets, stays in your browser and is gone when you close the tab.
Use cases
Where trimming an SVG down to its essentials pays off.
-
Inline icons and logos
SVGs embedded directly in HTML or a component ship on every page load. Optimizing them cuts the markup a browser has to parse and the bytes it has to download, on the assets users see first.
-
Icon sprite sheets
A sprite that stacks dozens of icons multiplies every wasted byte. Turn on Keep IDs first: the
<use>that pulls an icon out of the sheet lives in your page, not in the file, so without it the optimizer has no reason to believe any symbol is needed. -
CSS and data URIs
When an SVG is embedded as a background image or a data URI, every character counts and cannot be gzipped separately. A smaller source is the only lever you have.
-
Design-to-code handoff
Exports straight from Figma, Illustrator, or Sketch carry the most cruft. Run them through here before they enter the repository so your components start from clean markup.
See also
Need SVG to start from rather than shrink? Generate one with the SVG Pattern Generator, and when the icon is bound for a browser tab, turn it into every required size with the Favicon Generator.
Where the bytes in an SVG actually go
Optimizing an SVG is not the same as gzip compression, and it is not obfuscation. It removes markup a browser does not need while keeping the rendered image identical. Here is what goes, and why it is safe.
-
Editor metadata and comments
Design tools embed generator comments, XML prologs, private namespaces, and layer names as ids. None of it reaches the rendered image, so all of it is removed, apart from real comments you choose to keep. Ids are the one to think about: they are invisible to the renderer but not to the stylesheet, script, or sprite that may be addressing them from outside the file.
-
Wrapper groups and empty nodes
Exports often wrap a single shape in one or more
<g>elements that carry no transform or style. These collapse into their child, and truly empty containers and definitions are dropped entirely. -
Over-precise numbers
A coordinate written as 16.00000 means the same as 16, and 13.847221 rarely needs more than a couple of decimals on screen. Rounding path and coordinate data is usually the single biggest saving in an icon.
-
Long-hand colours and defaults
A six-digit hex such as #FFFFFF shrinks to #fff or the keyword, and attributes set to their default value are removed because the renderer assumes them anyway.
-
Compact path data
The d attribute of a path can be rewritten with relative commands, merged segments, and dropped separators to mean exactly the same curve in far fewer characters.
-
Why gzip is the number that counts
Servers send SVG compressed with gzip or brotli, which already collapse repeated whitespace. Optimizing still helps, because it removes what compression cannot and hands the compressor cleaner input, but judge the real gain by the gzip size rather than the raw bytes.
Best practices
Habits that keep optimized SVGs both small and visually intact.
- Always check the preview after optimizing, especially when you lower precision, and read anything the tool lists under the output. Rounding is where an aggressive setting can subtly distort curves, and a dropped id is where it can break something the preview cannot show you.
- Judge the gain by the gzip size, since that is what the server actually transfers. A large raw saving can shrink to little once transport compression is applied.
- Remove width and height when the SVG needs to scale to its container, but keep them for images that must have a fixed intrinsic size, such as email or some social embeds.
- Keep the viewBox. It is what lets an SVG scale cleanly, and this tool preserves it by default. Do not strip it in pursuit of a few extra bytes.
- Turn on Keep IDs whenever the SVG is a sprite, is styled by an external stylesheet, or carries an aria-labelledby. It costs a few percent and saves the references the default preset has no way to know about.
- Optimize as a build or handoff step and commit the result, but keep the editable source in your design tool. Optimized path data is not meant to be hand-edited.
Limitations
What this tool does, and what it leaves to other steps.
- It optimizes a single SVG document. It does not build sprite sheets, bundle referenced files, or inline external images and fonts.
- It will not rasterize an SVG to PNG or convert between formats. Pair it with the image converter when you need a bitmap.
- Scripts and interactivity inside an SVG are preserved but not analyzed, and never executed: the preview renders each file as an image, so nothing in it runs here. Optimization targets the drawing, not embedded JavaScript behaviour.
- A malformed document that cannot be parsed is reported rather than repaired, so badly broken input will not produce partial output.
FAQ
Common questions about optimizing SVG, what it changes, and when to use it.
Will optimizing change how my SVG looks?
With the default settings, no. The optimizer only removes markup a browser does not render and rewrites values to shorter forms that mean the same thing, so the image is identical. The one thing to watch is the Precision control: rounding coordinates too far can subtly distort fine detail, which is exactly why the side-by-side preview is there. Lower precision while watching the preview and stop before anything blurs.
What is the difference between optimizing and gzipping an SVG?
They work together. Optimizing edits the SVG markup itself, removing metadata, empty groups, and over-precise numbers a compressor cannot know are unnecessary. Gzip or brotli then compresses whatever you send, collapsing repetition on the wire. You want both: optimize first for the cleanest input, then let the server compress it for transport. Judge the real gain by the gzip figure shown here.
Should I remove the width and height attributes?
It depends on how the SVG is used. Removing them and keeping the viewBox lets the SVG scale fluidly to whatever container holds it, which is what you usually want for inline icons and illustrations. Keep them when the image needs a fixed intrinsic size, such as some email clients or social embeds that ignore the viewBox. The tool always preserves the viewBox either way.
How much smaller will my SVG get?
It depends entirely on how it was exported. Files straight from Figma, Illustrator, or Sketch carry the most slack, often shedding a third to two-thirds of their raw size, while an already-optimized icon may only shave a little. Once gzip is in play the percentage shrinks, because compression had already recovered much of the whitespace, which is why the gzip number is the honest one.
Is the viewBox safe? I heard removing it breaks scaling.
It is safe here. The viewBox is what makes an SVG resolution independent, so this tool keeps it by default and never strips it. Only the fixed width and height attributes are optional to remove, and doing that actually improves scaling rather than harming it.
Can I optimize an SVG with gradients, filters, or animation?
Yes. Gradients, filters, clip paths, masks, and SMIL or CSS animation are read and preserved, and a definition something in the file points at is kept along with the reference to it. Note that such an id is usually renamed to something short like a, which is invisible inside the file but matters if you inline several optimized SVGs on one page or address the id from outside. Keep IDs leaves the names alone.
Why did my sprite sheet come back empty?
Because a <symbol> that nothing in the same file uses looks like dead weight to the optimizer, and an icon sprite is made of exactly that: the <use> elements that pull the icons out live in your page, not in the sheet. Turn on Keep IDs and every symbol survives with its id intact. The tool flags this case under the output rather than letting a 100% saving look like a win.
Will optimizing break the CSS or JavaScript that targets my SVG?
It can, with the default settings. An id nothing inside the file references is removed, and one that is referenced is renamed to something short, so a rule like #logo-mark { fill: red } or a querySelector on that id stops matching. Turn on Keep IDs and every id is left exactly as written. The tool also lists any reference left pointing at nothing after a pass, including an aria-labelledby whose target lost its id.
Is my SVG uploaded anywhere?
No. Everything runs in your browser. The SVG you paste, any file you upload, and the result are processed locally, never transmitted or stored, and disappear the moment you close the tab, so even private logos and unreleased brand assets are safe. The preview renders each SVG as an image, which also means a file that references a remote URL is never allowed to fetch it from here.
Related tools
Keep going with the rest of the data and format toolkit.