What's Actually Bloating Your SVG Exports
Open an SVG exported straight from Illustrator, Figma, or Inkscape in a text editor, and it's usually a lot bigger than the shape it draws would suggest. None of that extra weight is required for the graphic to render — it's almost entirely artifacts of the export process itself, and it's worth knowing exactly what it is before deciding what's safe to strip.
Editor namespaces you'll never use
Inkscape exports commonly include an xmlns:inkscape and xmlns:sodipodi namespace declaration, plus attributes like inkscape:label or sodipodi:nodetypes scattered across elements — all of it metadata the editor uses internally to remember things like layer names and node-editing state for when you reopen the file in Inkscape specifically. A browser rendering the SVG ignores all of it completely; it exists purely so the originating editor can round-trip its own editing state.
A whole metadata block describing the file, not the image
Many exports include a <metadata> element containing RDF and Dublin Core data — author, creation date, source application, sometimes licensing info copied from a template. This is genuine data, just not data a browser does anything with when displaying the image. It's the SVG equivalent of a photo's EXIF data: informative in the right context, irrelevant to how the file actually renders.
Comments left over from the export process
A line like <!-- Generator: Adobe Illustrator 27.0.0, SVG Export Plug-In --> is common at the top of exported files — harmless, but pure overhead that serves no purpose once the file leaves the export dialog.
Coordinate precision far beyond what any screen can show
This is usually the single biggest contributor to file size on anything with curved or complex paths. A design tool's internal math often produces coordinates like 142.38571428571427, and that full value gets written straight into the exported d attribute — even though the visual difference between that and 142.39 is smaller than a single pixel could ever display. Multiply that unnecessary precision across every point in a complex path, and it adds up fast; a detailed icon can easily have hundreds of coordinate pairs, each carrying a dozen extra characters that contribute nothing visible.
Empty groups left behind by editing history
It's common for a design file's layer structure to include groups that once held something, got emptied out during editing, and never got cleaned up before export — an empty <g></g> costs a few bytes and does nothing.
What's worth keeping regardless
<title> and <desc> elements, along with aria-* attributes, are a different category entirely — they give the image an accessible name for screen readers, and stripping them trades a few bytes for worse accessibility. Unlike editor metadata, this is content a browser (or assistive technology) actually uses, so it's worth treating separately from the genuinely inert stuff above rather than removing everything indiscriminately in the name of a smaller file.
Clean up a batch
FreeToolDev's bulk SVG optimizer strips comments, editor namespaces, the metadata block, and excess coordinate precision from a whole batch of files at once, while keeping accessibility elements intact by default — all processed locally in your browser, with a before/after size shown for each file.