The Hidden Culprit Behind Bloated SVG File Size: Editor Namespaces
You've probably had the experience of saving a single icon and getting an SVG file that's far bigger than it has any right to be — the vector path data itself might be a few hundred bytes, yet the file weighs in at several kilobytes. The culprit is usually not the artwork at all, but the "editor-only metadata" that programs like Illustrator, Inkscape, and Figma quietly tuck into the file when they save. This guide explains exactly what that metadata is, why it's not needed on the web, and why it's safe to strip — backed by the tool's actual code and measured examples.
1. Why SVG bloats up like this in the first place
SVG is an XML-based text format, which means it can hold not just vector paths but literally any information you package as tags and attributes. That flexibility is exactly the problem. To restore the exact editing state when a file is reopened, programs like Illustrator, Inkscape, Figma, and Sketch save editor-internal details — layer names, lock states, zoom position, grid settings — directly inside the XML. None of that affects the rendered output, but every bit of it adds to the file size.
2. What is a namespace?
An XML namespace is a prefix system that lets a specific editor insert its own custom tags and attributes without colliding with the standard SVG spec. Inkscape uses the sodipodi: and inkscape: prefixes, Illustrator uses i: and serif:, Figma uses figma: and data-figma-, and Sketch uses sketch:. These exist purely so each program can mark a file as its own and store editing state — browsers and viewers that render SVGs simply ignore these prefixes entirely.
3. What actually ends up inside the file
Open a simple single-circle SVG saved from Inkscape and you'll typically find a <sodipodi:namedview> element (storing zoom, grid, and guide positions), a <metadata> block (license and author info), XML comments, and sometimes even a DOCTYPE declaration. On top of that, you'll commonly find empty <g> groups left over from edits that were later removed, and attributes with empty values like class="". None of these elements draw anything visually — they just take up space.
4. Measured example: a Figma export, before and after cleanup
We ran a sample SVG in the typical shape Figma exports it (containing empty <g> groups, XML comments, figma: attributes, and empty class/style attributes) through SVG Cleaner's cleanup logic and measured the byte counts.
| Stage | Bytes |
|---|---|
| Before cleanup | 767 |
| After cleanup (Illustrator/Figma namespaces, empty-group/comment options applied) | 587 |
| Savings | 180 bytes (about 23.5%) |
This example is on the short side, which caps the savings around 23%, but files with more layers and a longer editing history in Inkscape — where metadata makes up a bigger share of the file — commonly see 10–40% reductions.
5. What this site's SVG Cleaner actually removes
Looking at SVG Cleaner's code, the cleanup options are split by editor: Illustrator (i:, serif: namespaces and their related tags/attributes), Inkscape (sodipodi:, inkscape: namespaces), Figma (figma:, data-figma- attributes), and Sketch (sketch: namespace) can each be toggled independently. It also cleans up empty <g> groups (including nested empty groups, processed repeatedly), DOCTYPE declarations, XML comments, and empty attributes. The important detail is how the "remove unused namespaces" option behaves — it doesn't strip blindly. It first checks whether a given prefix is actually referenced anywhere in the document body, and only removes xmlns: declarations that turn out to be genuinely unused, leaving essential declarations like a still-used xmlns:xlink intact.
6. Why cleanup is safe, and what to watch for
Elements that affect rendering — paths, fills, gradients, filters, viewBox, and so on — belong to the standard SVG namespace, so they're left untouched regardless of editor-namespace removal. That said, elements marked visibility:hidden are deliberately excluded from removal, since CSS or JS might reveal them later. When you turn on several cleanup options at once, it's a good habit to actually render the result and eyeball it once before shipping. If you're converting the icon to PNG for distribution afterward, check out SVG to PNG, and for favicon use, Favicon Maker.
Frequently Asked Questions
Q. If I strip the namespaces, will it cause problems reopening the file in Illustrator or Inkscape?
Editing state (layer locks, zoom position, etc.) will be lost, but the artwork itself stays intact. It's a good idea to keep the cleaned-up copy for web deployment separate from your original source file.
Q. Does it remove namespaces that are actually in use, like xmlns:xlink?
No. The "remove unused namespaces" option checks actual usage in the document body first, so if a prefix like xlink: is referenced anywhere, its xmlns declaration is preserved.
Q. How much smaller does the file get after cleanup?
It varies by editor and file complexity, but in measured tests even a short file shrank by over 20%, and Inkscape files with heavy metadata commonly saw 10–40% reductions.
Q. Is "cleaning" different from "optimization"?
Yes. Cleaning focuses on removing editor metadata that has nothing to do with rendering, while optimization includes more aggressive compression like reducing the decimal precision of path coordinates. SVG Cleaner combines both functions in one tool.