Where the bytes actually are
Open an icon exported from a design tool and most of what you see is not the drawing. There is a generator comment naming the application and version, an XML declaration and sometimes a DOCTYPE, an RDF <metadata> block carrying licence boilerplate, a sodipodi:namedview element that stores the editor's zoom level and grid settings, namespaced attributes such as inkscape:label and serif:id, a nest of <g> elements that used to be layers and now wrap nothing, and coordinates written as 12.345678901234.
None of that affects rendering. On a 24 x 24 icon the path data is commonly one or two kilobytes and the file is eight, which means most of what you ship is a record of how the file was made.
What this strips and what it keeps
| Removed | Kept |
|---|---|
| Comments, XML declaration, DOCTYPE | xmlns — added back if missing |
<metadata>, sodipodi:namedview | viewBox |
| Editor namespaces and attributes | Every presentation attribute — fill, stroke, opacity, transform |
version, baseProfile | ids referenced by url(#…), href="#…" or a CSS selector |
| Empty groups, whitespace between tags | <title> and <desc>, unless you opt out |
| ids nothing points at | Structure — no element is merged, converted or moved |
Two things here can break a file
Removing viewBox. This tool does not remove it, and no minifier should, but it is worth knowing why it matters because some optimiser configurations will. viewBox defines the coordinate system the drawing lives in, and it is what lets the SVG scale to whatever box you put it in. Without it the image renders at its intrinsic width and height and ignores your CSS sizing — you get a crop, or a small graphic marooned in a large container. If the output above loses its viewBox, something is wrong with the source and you should stop.
Removing ids. An id in SVG is not decoration. Gradients, clip paths, masks, markers, filters and <use> elements all work by pointing at an id, and a stylesheet inside the file can select on one too. Delete an id that something references and the gradient renders as flat black, or the clipped shape stops being clipped. The scan here counts every #name occurrence in the file and keeps any id that appears, including inside CSS selectors and url() references. It cannot see a reference that lives outside the file — an external stylesheet, or JavaScript that does getElementById on an inline SVG. If your ids are addressed from outside, turn that option off.
Rounding coordinates
On a viewBox="0 0 24 24" icon, two decimal places is one hundredth of a user unit — well under a device pixel at any realistic display size, and invisible. The setting stops being safe when the coordinate system is small: a viewBox="0 0 1 1" normalised path rounded to two places has been quantised to a 100 x 100 grid, and curves will visibly kink. Long smooth curves defined by many nearby control points are the other case to watch.
Values carrying a unit — 2.5px, 33.333%, 1.5em — are left alone, since rounding those changes layout rather than geometry. The two previews are there to be compared; if they differ, raise the setting or turn rounding off.
Against a real optimiser
SVGO parses the document into a tree and runs dozens of plugins over it: converting absolute path commands to relative, folding transforms into coordinates, merging adjacent paths, shortening #ffffff to #fff, collapsing useless groups while preserving inherited attributes. It gets further, and because it understands the structure it can do so more safely on complex files.
This tool does the safe text-level subset, which typically lands somewhere between 30 and 60 percent on a design-tool export and does not require a build step. If you have a pipeline, use SVGO in it. If you have four icons and a deadline, paste them here, compare the previews, and move on.
Questions people ask
The image changed after cleaning.
Decimal rounding is the first suspect — set it to "Do not round" and compare again. If it still differs, an id was removed that a CSS rule or a gradient reference depended on, so turn off the id option. The two previews are rendered from the actual before and after strings, so anything you can see there is real.
Is this worth doing if the server gzips everything?
Partly. Gzip handles repeated whitespace very well, so that portion of the saving largely evaporates. Metadata blocks, editor attributes and long decimal strings are distinct content and survive compression as real bytes. For inline SVG there is a second reason: the markup is parsed as part of the HTML document, so a smaller file is less DOM to build.
Can I run animated or scripted SVG through it?
Not safely. Whitespace collapsing runs across the whole file including the contents of CDATA sections, so a script or a stylesheet with meaningful line breaks can come out broken. The output is checked for well-formedness and you will get a warning, but a file that still parses can still behave differently. Use a structure-aware optimiser for those.
Should I remove title and desc?
Only when the SVG is decorative or used as a CSS background or an img src, where nothing reads them. For inline SVG they are the accessible name and description — the equivalent of alt text — and removing them takes the graphic away from screen reader users to save a few dozen bytes. That is why the option is off by default.