Why an exported SVG is bigger than the drawing inside it
An SVG saved straight out of a design tool rarely contains just the drawing. Illustrator, Figma, Sketch, and Inkscape all routinely embed their own metadata alongside the actual paths: an editor-specific XML namespace, a metadata block describing the authoring application, comments left over from the export process, and coordinate values carried out to eight or ten decimal places of precision that no screen will ever render a visible difference for. None of it changes how the image looks — it's overhead that exists purely because the file passed through a particular piece of software on its way to you.
What's actually safe to strip, and what isn't
Comments, editor-specific namespaces (inkscape:, sodipodi:, and similar), empty groups left behind by other cleanup, and excess numeric precision are all non-rendering — removing them can't change how the SVG displays, full stop. Rounding coordinate precision from, say, ten decimal places down to two is the one item on that list with a theoretical edge, but the difference at that level of precision is a fraction of a screen pixel, invisible in practice. What's genuinely different in kind is geometry-level optimization — merging overlapping paths, simplifying curves, converting shapes to more compact equivalents — which can occasionally introduce a subtle visual change that's easy to miss in a diff and only noticed later. A safe cleanup pass sticks to the first category; a more aggressive optimizer's advanced plugins live in the second.
Clean up your SVG
One thing worth keeping deliberately: title and desc
The <title> and <desc> elements inside an SVG aren't editor cruft — they're what a screen reader announces for the image, filling the same role alt text plays on an <img> tag. It's worth stripping them only when an icon is genuinely decorative and already has accessible text elsewhere on the page (a button with its own visible label, for instance); otherwise, removing them for the sake of a slightly smaller file trades away real accessibility for a marginal size saving that usually isn't worth it.
Why the extra weight matters more for SVG than other assets
A bloated SVG matters more than an equivalently bloated photo, because of how differently the two get used. A photo loads once per page as an external file the browser can cache. An icon SVG is frequently inlined directly into HTML, JSX, or a CSS background-image, and the same icon might appear a dozen times across a single page — a navigation bar, a list of cards, a footer — with every inlined copy carrying its own metadata bloat rather than sharing one cached file. Multiply a few extra kilobytes of editor cruft by a dozen repeated icons and it adds up to real, measurable page weight.
What to do if you need more than a cleanup pass
For most icons and simple illustrations, stripping non-rendering metadata gets the large majority of the available size reduction with zero visual risk. If you're working with a genuinely complex illustration and need geometry-level optimization on top of that — path merging, curve simplification — a build-pipeline tool with a full plugin set is the right next step, ideally paired with a visual diff check before shipping the result, since that category of change is the one place a safe assumption doesn't automatically hold.