SVG Optimization: Shrink Files by 60% Without Losing Quality

SVGs exported from design tools are rarely production-ready. They carry editor metadata, redundant attributes, excessive decimal precision, and invisible elements that inflate file sizes without contributing anything visual. A 15 KB icon that should be 3 KB is a common sight. This guide explains what causes the bloat and how to eliminate it.

What bloats SVGs

Editor metadata

Illustrator, Figma, Sketch, and Inkscape all embed metadata in their SVG exports. This includes XML namespaces, generator comments, layer names, and proprietary attributes that browsers ignore completely.

A typical Illustrator export starts with something like this:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 28.0, SVG Export Plug-In . SVG Version: ... -->
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     x="0px" y="0px" viewBox="0 0 24 24"
     style="enable-background:new 0 0 24 24;"
     xml:space="preserve">

The comment, the xmlns:xlink (if unused), x="0px", y="0px", the style attribute, and xml:space are all unnecessary. Removing them saves bytes on every single SVG.

Excessive decimal precision

Design tools export coordinates with 6+ decimal places:

<path d="M12.000001,3.999999 L23.999998,12.000002"/>

For a 24x24 icon, two decimal places are more than enough:

<path d="M12,4 L24,12"/>

Reducing precision from 6 to 2 decimal places can shrink path data by 30-40%.

Redundant attributes and default values

Attributes that match the SVG default can be removed. fill="black", stroke="none", opacity="1", fill-rule="nonzero" -- these are all defaults and add bytes without changing rendering.

Hidden and empty elements

Empty <g> groups, invisible layers, clipping paths that clip nothing, and elements with display="none" add to file size without rendering anything.

Inline styles vs attributes

Some tools export styles as inline CSS:

<path style="fill:#ff0000;stroke:#000000;stroke-width:2"/>

Converting to presentational attributes is often shorter:

<path fill="#f00" stroke="#000" stroke-width="2"/>

Note the shortened hex colors -- #ff0000 becomes #f00 when all three pairs are doubles.

Automated optimization with SVGO

SVGO (SVG Optimizer) is the industry-standard tool. It applies a pipeline of plugins that handle all the optimizations described above, plus many more.

Using SVGO via CLI

# Install
npm install -g svgo

# Optimize a single file
svgo input.svg -o output.svg

# Optimize all SVGs in a directory
svgo -f ./icons -o ./icons-optimized

# Show file size comparison
svgo input.svg --pretty --indent=2

Common SVGO configuration

Create an svgo.config.js file to customize the pipeline:

module.exports = {
  plugins: [
    'preset-default',
    'removeDimensions',        // Use viewBox instead of width/height
    'removeOffCanvasPaths',
    {
      name: 'removeAttrs',
      params: {
        attrs: ['data-name']   // Remove specific attributes
      }
    },
    {
      name: 'preset-default',
      params: {
        overrides: {
          removeViewBox: false,       // Keep viewBox (important!)
          cleanupIds: {
            minify: false             // Keep readable IDs
          }
        }
      }
    }
  ]
};

Important: Never remove viewBox. It is essential for responsive scaling. SVGO's default config preserves it, but double-check if you customize the pipeline.

Manual optimization tricks

Simplify paths

Complex shapes can sometimes be redrawn with fewer points. In Illustrator, use Object > Path > Simplify. In Inkscape, use Path > Simplify. Even a small reduction in anchor points can significantly shrink path data.

Use basic shapes instead of paths

A <rect>, <circle>, or <line> is shorter than the equivalent <path>:

<!-- Path: 42 bytes -->
<path d="M0,0 L24,0 L24,24 L0,24 Z"/>

<!-- Rect: 32 bytes -->
<rect width="24" height="24"/>

SVGO has a convertShapeToPath plugin that goes the other direction (shapes to paths), which is useful for consistency. But if you are hand-authoring SVGs, prefer basic shapes.

Merge paths with the same style

Multiple <path> elements with identical fill and stroke can be merged into a single path:

<!-- Before: two paths -->
<path d="M4,4 L8,4 L8,8 Z" fill="#333"/>
<path d="M12,4 L16,4 L16,8 Z" fill="#333"/>

<!-- After: one path -->
<path d="M4,4 L8,4 L8,8 ZM12,4 L16,4 L16,8 Z" fill="#333"/>

Use currentColor

For monochrome icons, replace hardcoded fill values with currentColor. This lets the icon inherit the text color via CSS, eliminating the need for multiple color variants:

<svg viewBox="0 0 24 24" fill="currentColor">
  <path d="M12 2L2 22h20z"/>
</svg>

.icon { color: #333; }
.icon:hover { color: #0066cc; }

When to use SVG vs other formats

SVG is ideal for:

• Icons and logos
• Illustrations with flat colors and clean lines
• Charts and data visualizations
• Anything that needs to scale to any resolution

SVG is not ideal for:

• Photographs (use WebP or AVIF)
• Complex illustrations with many gradients and textures (use PNG or WebP)
• Animations with many frames (use video or Lottie)

A good rule of thumb: if the SVG is larger than the equivalent PNG at 2x resolution, use the PNG.

SVGs and performance

Inline vs external

Inline SVGs (embedded in HTML) save an HTTP request and allow CSS styling. External SVGs (loaded via <img> or CSS background) benefit from caching and do not bloat the HTML document.

For icons used on every page, inline is usually better. For decorative illustrations used on a single page, external is cleaner.

SVG sprites

If you have dozens of icons, an SVG sprite sheet keeps the HTML clean:

<!-- sprite.svg -->
<svg xmlns="http://www.w3.org/2000/svg" style="display:none">
  <symbol id="icon-search" viewBox="0 0 24 24">
    <path d="..."/>
  </symbol>
  <symbol id="icon-menu" viewBox="0 0 24 24">
    <path d="..."/>
  </symbol>
</svg>

<!-- Usage -->
<svg><use href="sprite.svg#icon-search"/></svg>

Gzip compression

SVGs are XML text, which compresses extremely well. A 10 KB SVG typically compresses to 2-3 KB with gzip. If your server supports gzip or brotli (and it should), the on-wire size is much smaller than the file size. This means optimizing the file itself and letting the server compress it gives you the best of both worlds.

Measuring your gains

Before optimizing blindly, measure the baseline. Check the file size, then run SVGO, then check again. Aim for:

• Icon SVGs (24x24): under 1 KB optimized
• Simple illustrations: under 10 KB optimized
• Complex illustrations: if over 50 KB optimized, consider PNG/WebP

A quick command to check sizes across a directory:

find ./icons -name "*.svg" -exec ls -la {} \; | awk '{total+=$5; count++} END {printf "Files: %d, Total: %.1f KB, Avg: %.1f KB\n", count, total/1024, total/1024/count}'

Try our SVG Optimizer to optimize your SVGs instantly -- paste or upload your SVG and see the size reduction in real time, right in your browser with no server upload required.