How to Optimize SVG — Cut File Size 2–10× with Zero Quality Loss

SVG has a reputation as a lightweight format — but open a file exported from Illustrator or Figma and you'll find editor metadata, commented‑out junk, coordinates with eight decimal places and styles duplicated on every shape. A typical exported SVG can shrink 2–10× without changing a single on‑screen pixel. Here's how.

Where the junk comes from

SVG is text, and editors write whatever suits them:

• Editor metadata: <metadata>, "Generator: Adobe Illustrator" comments, private sodipodi:/inkscape: attributes — browsers need none of it.
• Excess precision: 12.000000381469727 instead of 12 — invisible to the eye, heavy across thousands of points.
• Empty groups and defs: layer remnants, unused gradients, contentless wrappers.
• Duplicated styles: fill="#21A038" on each of 40 shapes instead of once on a group.
• Hidden objects: shapes with display:none or outside the viewBox — drawing‑process artifacts that rode along into the export.

Automation: SVGO and SVGOMG

SVGOMG is the web UI: drop a file, toggle options, download — before/after size shown live. Perfect for one‑offs.

SVGO is the CLI for batches and build pipelines:

npx svgo logo.svg              # one file
npx svgo -f ./icons -o ./dist  # a whole folder

Defaults are safe. Two toggles deserve caution:

• Precision. 2–3 decimals — safe; 1 — can visibly distort fine details and smooth curves.
• Remove viewBox. Leave it off: without a viewBox the SVG stops scaling via CSS — the classic "I embedded the SVG and it won't resize".

Manual techniques automation can't do

Find raster hiding inside

The top answer to "why is my SVG 800 KB": a base64 bitmap inside the vector (<image href="data:image/png...). Technically SVG, actually a PNG in a wrapper with all raster downsides. Search for the <image> tag — if present, the file needs redrawing, not optimizing.

Convert text to outlines — or the reverse

A <text> tag renders with the viewer's fonts: font missing — the label jumps to a fallback. Logos should have text outlined (Outline/Flatten in your editor). The flip side: each outlined letter is dozens of points, and long labels bloat the file. Icons and logos — outlines; diagrams with many labels — <text> with system fonts.

Simplify paths

Figma: select → Flatten, then delete excess points. Inkscape: Path → Simplify (Ctrl+L) — reduces node count with adjustable aggression. Especially useful after auto‑tracing, which loves to put a node on every pixel.

Merge identical fills

Forty shapes of one color? Group them and set the fill once on the group. Recoloring gets easier too — the very thing our logo color editor relies on.

Real‑world numbers

Kilobytes look petty until a page carries thirty icons: that's the gap between "instant" and "visibly loading", especially on mobile. And inline SVG ships inside the HTML — its weight is every page's weight.

Gzip and Brotli: the final multiplier

SVG is text, and text compresses beautifully on the fly. A properly configured server serves SVG with Brotli or Gzip — another 60–80% off the transferred size. Check in DevTools → Network → the Size column: transferred far below size means compression is working.

Automation: SVGO in the project pipeline

Manual optimization suits one‑off files; projects with dozens of icons bake it into the process:

• A config in the repo. svgo.config.js fixes the settings for the whole team — e.g. removeViewBox off, precision 3:

module.exports = {
  plugins: [
    { name: 'preset-default',
      params: { overrides: { removeViewBox: false } } },
  ],
};

• A hook or CI step: running svgo over changed files on pre‑commit means unoptimized SVG physically can't enter the repo.
• Bundlers: Vite/Webpack plugins optimize SVG on import; in React projects SVGR combines optimization with turning icons into components.
• Figma plugins (SVGO Compressor and kin) optimize at export time — handy for designers handing files to developers.

One principle: optimization must happen by itself, not by memory. "Remembering to run SVGOMG" doesn't survive contact with deadlines.

Dissecting a real file: what exactly gets thrown out

A typical editor export, junk annotated line by line:

<?xml version="1.0" encoding="UTF-8"?>            ← unneeded on the web
<!-- Generator: Adobe [Illustrator](../../logos/design/illustrator/) 27.0 -->         ← a business-card comment
<svg xmlns:xlink="..." xml:space="preserve"        ← unused attributes
     width="24.000000px" height="24.000000px">     ← trailing zeros
  <g id="Layer_1_copy_2">                          ← the editor's layer name
    <path fill="#FF0000" d="M12.000000,2.000000    ← 6 decimal places
      C12.000000,2.000000 11.999999,2.000001..."/>  ← curve micro-jitters
  </g>
</svg>

After SVGO, the essence remains:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path fill="red" d="M12 2C12 2 12 2..."/>
</svg>

Each junk line is harmless alone — but there are hundreds per file and dozens of files. That's how 4 KB becomes 1 KB with zero visible change.

When optimization is NOT needed

For honesty — the cases where you can skip it:

• A single logo on a static landing page — 3 KB changes nothing measurable.
• SVG for print or designer handoff — layer structure matters there, and aggressive optimization collapses it. Optimize a web copy; keep the source intact.
• Files still being edited — optimization irreversibly simplifies structure: layer names, groups and guides vanish.

The rule: an optimized SVG is a production artifact, like minified JS. The source lives separately.

In short

SVGO/SVGOMG with defaults is a mandatory step for any SVG headed to production. Then situationally: evict embedded raster, outline text, simplify traced paths. And never remove the viewBox.

Every SVG in our logo catalog is already optimized and normalized — download or copy code with no junk, metadata or surprises inside.