SVGO multipass: smaller SVGs without guessing when to stop

One pass often leaves savings on the table

You run SVGO on an SVG, the file gets smaller, and you move on. Later you notice attributes or groups that could still be removed. This happens because SVGO works as a pipeline of plugins. One plugin might simplify a path, which then makes a color conversion or path merge possible, but only if the optimizer runs again. A single pass stops before those second-order savings appear.

The useful takeaway: enable multipass when you optimize complex SVGs as part of a build step, but treat the result as untrusted until you open it in a browser. Multipass repeats the plugin pipeline until no further changes occur or a safety limit is reached.

How multipass changes the optimization loop

SVGO plugins operate on the SVG document tree. removeMetadata strips comments, convertColors rewrites color values, and mergePaths combines adjacent path data. In multipass mode, SVGO feeds the output of one full pass back into the start of the pipeline. If convertColors produces a color format that another plugin can simplify further, that simplification happens on pass two instead of being missed.

SVGO stops when a pass produces no changes, meaning it has converged. It does not run forever. The default is a single pass; multipass must be opted into.

Worked example: enable multipass and compare output

Run this from your project root in a terminal. You need read permission on the source SVG and write permission for the destination file.

npx svgo input.svg -o output.svg --config .svgo.config.js

Placeholder meanings:

• input.svg: the unoptimized SVG file.
• output.svg: the optimized result.
• .svgo.config.js: your SVGO configuration file.

A minimal config that turns multipass on:

module.exports = {
  multipass: true,
};

To diagnose whether multipass helped, compare file sizes before and after:

wc -c input.svg output.svg

Expected check: output.svg should be smaller than input.svg. If multipass is enabled and the size barely changes, your SVG may already be stable after one pass. Open both files in a browser and compare them side by side. If shapes, colors, or text positions differ, the optimizer introduced a visual regression, meaning the SVG looks different than intended.

Risk: SVGO overwrites the destination file without warning. Back up source assets before batch optimization, especially in a shared asset folder.

Trade-offs and limitations

• Build time: Each additional pass parses and traverses the SVG tree again. For large icon libraries, multipass can noticeably increase build duration.
• Visual regressions: Aggressive plugins such as convertColors or mergePaths can occasionally alter rendering in complex SVGs. Multipass gives those plugins more opportunities to interact, which increases—but does not eliminate—that risk.
• Diminishing returns: Most SVGs converge after two or three passes. Running more passes rarely saves meaningful bytes.

Practical verification before you ship

1. Run SVGO with multipass: false and record the output size.
2. Run with multipass: true and record the output size.
3. Open both outputs in a browser at the same zoom level and compare paths, fills, and text.
4. If the multipass version is smaller and visually identical, use it in your build configuration.

Closing recommendation

Turn multipass on for build-time SVG optimization where file size matters more than milliseconds of build time. Keep single-pass mode for quick local checks or watch-mode rebuilds where speed matters most. Always verify the final SVG in a browser before deploying, because a smaller file that renders incorrectly is not an optimization.