Make an SVG smaller without breaking it
A drawing program saves a great deal that a browser never reads: a prolog, a generator comment, the position of the window you had open, layer names, and coordinates written to five decimal places nobody can see. Paste the markup above and it comes back with all of that gone and the drawing untouched. You get the two sizes, a list of what was taken out, and the result drawn as a picture so you can check for yourself that nothing moved.
Make an SVG smaller
Paste an SVG and get a smaller one back, ready to paste inline. It says what it took out as well as how many bytes went, because a tool that quietly rewrites your markup and shows you one number is asking for a lot of trust. The file is read and rewritten by this tab, on your own machine, so the markup you paste is not uploaded anywhere.
Optimise SVG, step by step
- Paste the SVGOr choose the file. Either way it is read in this tab, and the optimiser itself is only fetched once you have actually pressed the button.
- Read what it took outEvery line is counted from your own file rather than assumed, so it says three comments because there were three, not because exports usually have some.
- Check the picture, then copy itThe preview underneath is drawn from the optimised markup, not the original, so if a shape did move you will see it before you paste anything anywhere.
Why the viewBox stays, when the tool everybody uses used to drop it
This runs SVGO, which is the library behind most of the optimisers on the web, at its default settings with one exception that is worth knowing about. For years those defaults included a step that deleted the viewBox from any file whose width and height agreed with it. The logic was that the attribute was redundant, and it is, right up until somebody puts the picture in a box of a different shape, at which point the file has no idea what its own proportions are and stops scaling. It is the single most complained about default in the library's history and it was finally taken out of the preset in version four, which is the version here. The behaviour is asserted by a test rather than trusted to a version number: a file that has a viewBox comes out with the same one, including the case where it also carries a width and a height, which is exactly the shape that used to lose it.
Nearly every SVG on the web is bigger than it needs to be, and almost none of it is the drawing’s
fault. Open one from a design tool in a text editor and you will find a couple of lines of XML
ceremony, a comment naming the program and its version number, two or three namespaces belonging to
features nobody used, a record of which layer was selected, and coordinates like 10.000000004.
The browser reads none of it. It is all just there, in every copy, on every page load.
Taking it out is not clever and it is not risky, which is why it is worth doing to every file that goes near a page. What is occasionally risky is the next tier: rounding numbers, merging paths and collapsing groups. Those are on here, at the library’s own defaults, because they are where most of the saving actually is, and the preview is there so you never have to accept them on trust.
If the result is going into a React project, it is worth running this first and converting it second. The converter deliberately does not touch the drawing, so a file optimised beforehand produces a component that is smaller and quite a lot easier to read.
Questions
Will this change how my picture looks?
It should not, and you can check without taking my word for it, because the preview under the result is drawn from the optimised markup rather than from what you pasted. The risky part of any optimiser is rounding coordinates, and the defaults here round to a precision that is invisible at any size a screen can show.
What does it actually take out?
Whatever your file had. Usually the XML prolog, the generator comment, editor namespaces and layer names, metadata blocks, groups that wrap a single shape, attributes set to values that were already the default, and several decimal places of path data. The list under the result is counted from your own file, so it never claims to have removed something that was never there.
Is this the same thing as SVGOMG?
Same library underneath, different pitch. SVGOMG hands you fifty plugin switches, which is wonderful if you know what all fifty do. This runs the sensible defaults, tells you in plain English what went, and gets out of the way. If you need to turn an individual step off, SVGOMG is genuinely the better tool and I would use it.
Are animations and scripts safe?
Animations survive, and a script inside the file is left alone and flagged rather than removed, because deleting code out of somebody's file without asking is not a decision an optimiser gets to make. If the file is going into your own page, read that script before you paste it.
Does the file leave my machine?
The file does not. The optimiser is a library that runs in this tab, downloaded to your browser the first time you press the button and then working entirely on your own machine. The page records that an optimisation happened, carrying nothing but which tool it was, so no file name, no size and none of your markup.
Other things here
There is a full list on the free tools page. They all work the same way: in the browser, with nothing to install.
The tool is free. So is the thought.
This page did one small job. Edmund is for the thing you thought of while doing it: a capture app for iPhone, iPad and Mac that files a note the moment you have it, so it does not get lost between having it and writing it down.
See what Edmund does