DEV Community

Michael Lip
Michael Lip

Posted on • Originally published at zovo.one

Your SVGs Are Probably 10x Bigger Than They Need to Be

#svg #webdev #performance #optimization

I exported an icon from Figma last week. The SVG was 14KB. After optimization, it was 1.2KB. Same visual output, 91% smaller. This is not unusual. Design tools embed metadata, use excessive precision, include redundant groups, and output verbose path data that inflates file size dramatically.

When you have one icon, 13KB of waste does not matter. When you have 50 icons inline in your HTML, that is 650KB of unnecessary markup being parsed on every page load.

What makes SVGs bloated

Editor metadata. Illustrator, Figma, Sketch, and Inkscape all embed their own metadata. Illustrator adds <!-- Generator: Adobe Illustrator 27.0 --> comments, proprietary namespaces like xmlns:x, and processing instructions. None of this is needed for rendering.

Excessive decimal precision. A path point at x="142.38472947" renders identically to x="142.38". Design tools often output 8-10 decimal places. For most SVGs, 2 decimal places is sufficient. On a complex illustration with 500 path points, trimming 6 unnecessary decimal places per coordinate saves significant bytes.

Redundant groups and transforms. Design tools wrap elements in nested <g> tags with identity transforms, empty style attributes, and unused IDs. A single rectangle might be wrapped in three groups that serve no purpose.

Unoptimized paths. Path data uses commands like M (move to), L (line to), C (cubic bezier). Design tools often use absolute coordinates everywhere when relative coordinates would be shorter. They use L for horizontal and vertical lines when H and V are more compact. They fail to merge consecutive segments that can be simplified.

<!-- Before optimization -->
<path d="M 100.000000,200.000000 L 200.000000,200.000000 L 200.000000,300.000000 L 100.000000,300.000000 Z"/>

<!-- After optimization -->
<path d="M100 200h100v100H100z"/>
Enter fullscreen mode Exit fullscreen mode

Same rectangle. 95 characters vs. 28 characters.

The optimization pipeline

A thorough SVG optimization pass includes:

  1. Remove metadata and comments. Strip editor-specific namespaces, comments, processing instructions, and <metadata> elements.

  2. Remove hidden elements. Elements with display="none", zero-size elements, and elements completely outside the viewBox.

  3. Collapse groups. Remove <g> elements that have no attributes or only have inheritable attributes that can be moved to children.

  4. Optimize path data. Convert absolute to relative coordinates where shorter. Replace L with H/V for axis-aligned segments. Remove redundant M commands. Trim decimal precision.

  5. Merge paths. Multiple <path> elements with the same style can often be merged into a single path, eliminating duplicate style attributes.

  6. Round and simplify. Round numeric values. Remove default attribute values (like fill-opacity="1"). Convert colors to shortest form (#ffffff to #fff).

  7. Remove unused definitions. <defs> blocks often contain gradients, filters, and clip paths that are not referenced by any element.

Measurable impact

I ran optimization on a set of 30 UI icons from a production project:

  • Total before: 186KB
  • Total after: 23KB
  • Average reduction: 87%
  • Largest single reduction: 96% (a complex illustration)
  • Smallest single reduction: 62% (a simple geometric icon)

For inline SVGs, this directly reduces HTML document size. For externally referenced SVGs, it reduces HTTP payload. Either way, it is free performance.

When optimization goes wrong

Aggressive optimization can break SVGs. The most common issues:

  • Removing IDs that are referenced by CSS or JavaScript
  • Collapsing groups that have event listeners attached
  • Merging paths that need to be separately interactive
  • Removing xmlns attributes needed for standalone SVG files
  • Over-rounding coordinates on detailed illustrations, causing visible distortion

The solution is always to compare the optimized output visually against the original. Automated optimization should be reviewed, not blindly trusted.

The tool

I built an SVG optimizer at zovo.one/free-tools/svg-optimizer that runs the full optimization pipeline with configurable aggression levels. You can toggle each optimization pass independently, preview the result side-by-side with the original, and see the byte savings in real time. Paste your SVG, adjust the settings, and copy the optimized output.

I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.

Top comments (0)