Paste the markup instead
Settings
Fewer decimals, less weight. Below two, watch the check.
Before and after
Optimised markup
How to use it
01
Drop the file
Drag it, pick it, or paste the code directly. The first run takes a moment to prepare the optimiser.
02
Adjust if needed
The defaults are deliberately conservative. Decimal precision is the lever that moves the most.
03
Read the check
We draw the original and the result and compare them pixel by pixel. If something changed, it says so before you take it.
04
Download or copy
The optimised file, ready. If you are inlining it into HTML, the copy button saves you the step.
What gets removed, and what does not
An aggressive optimiser always wins on the scales. The question is what it takes with it, so here is the policy, written down.
| What | Policy |
|---|---|
| Comments and metadata | Always removed. Nobody reads them except the editor that wrote them. |
| Illustrator, Inkscape and Figma data | Always removed. It is half the weight of a typical export. |
| Decimals in path data | Trimmed to the precision you choose. Three decimals is invisible; zero wrecks the drawing. |
| <title> and <desc> | Kept by default: they are the icon’s name for a screen reader. |
| The viewBox | Kept by default. Without it the SVG stops scaling and shows at its original size. |
| The ids | Kept by default: your page’s CSS or JavaScript may be pointing at them. |
Why we verify the result
Before building this we tried writing our own optimiser. In fifteen minutes it compressed nearly as well as the one we use now… and wrecked four of the five test files. One came out completely blank: it had deleted some internal labels that looked useless, and they were exactly the ones giving the drawing its colour.
That is the hard part of a tool like this: not compressing, but not ruining anything. Which is why we use SVGO inside — a free, open program that has spent years collecting fixes for the odd cases — and why the result is drawn and compared before it is offered to you. Compressing is easy; answering for the result is the job.
Frequently asked questions
Is my file uploaded to a server?
No. The file is read in your browser, optimised in your browser and downloaded from your browser. There is no network request carrying your content, to us or to anyone. You can confirm it in the network tab of your developer tools.
What engine does it use inside?
SVGO, the open-source library half the industry uses for this, under the MIT licence. We have not rewritten it and we are not hiding it: what is ours is everything around it — the interface, the defaults, and the check that the result still looks the same. That is what a serious studio does: not reinvent a proven part, and answer for how it is integrated.
Why does the first optimisation take a moment?
Because the optimiser is around 550 KB of JavaScript and we would rather not charge that to someone who only came to read the page. It downloads the first time you drop a file, and runs on a separate thread so the interface does not freeze even with a large SVG. After that, every optimisation is instant.
Why keep <title> when SVGO can remove it?
Because an SVG without a title is a mute icon: a screen reader has nothing to announce. It saves a few bytes and costs accessibility, so the default is to keep it. If the SVG is purely decorative and marked aria-hidden, removing it bothers nobody — and the checkbox is there.
What decimal precision should I use?
Three is the default and is invisible in any normal use. For small icons you can drop to one or two and save considerably more. Zero usually wrecks the drawing: try it and watch the check, which is exactly what it is for.
The check says “minimal differences”. Is that a problem?
Almost never. It is usually edge antialiasing, where moving a point by thousandths shifts a fraction of a tone. It is reported separately from “identical” so the call is yours, not ours; if the SVG is a logo about to go up on a billboard, look at the preview before signing it off.
Can it break something the comparison cannot see?
Yes, and that is worth saying: a snapshot does not see animations, or an id your page’s CSS or JavaScript points at, or the behaviour of an SVG used as a sprite. That is why ids are kept by default. The check catches the most common failure — the drawing changing — not every possible one.
What about SVGs with embedded images?
They work the same, but if those images come from another domain the browser will not let us read the canvas they are drawn on, so the comparison cannot run and is flagged as “not verifiable”. The optimised file is still valid; what is missing is our guarantee that it looks identical.
One SVG is light. A whole site, not always
Optimising one file by hand is fine. When the problem is a whole site taking three seconds to show up, what you need is to measure where that time goes and tackle it at the source.
We reply within one business dayBogotá · UTC−5