Is removeViewBox still the correct default in SVGO v3/v4?

Short answer

No — the premise is outdated. In SVGO v2, removeViewBox was part of the default preset and stripped the viewBox attribute. In SVGO v3 (and carried into v4), the plugin is disabled by default, so viewBox is preserved unless you explicitly enable the plugin. If you upgraded and your icons suddenly scale correctly again, this change is why. If you upgraded and icons broke, the cause is almost certainly something else in your config — for example carrying over an old v2 config that explicitly enables the plugin, or a related plugin like removeDimensions.

Why the default changed

Removing viewBox is only safe when the SVG has fixed width and height attributes that exactly match the viewBox coordinate space. In that narrow case the attribute is redundant and dropping it saves bytes. But the moment the SVG is used responsively — scaled via CSS, used as an icon font source, inlined without dimensions, or embedded with <img> in a fluid layout — the viewBox is what tells the browser how to map the internal coordinate system to the rendered size. Without it, the SVG renders at a fixed size or clips. Because that failure mode is silent and visual, the maintainers moved the plugin out of the default preset. Treat this as the confirmed behavior for v3/v4, but verify against the release notes of the exact minor version you install, since preset contents have shifted between minors.

Which projects should do what

• Icon libraries, design systems, anything inlined and sized with CSS: leave the default alone (plugin off). The viewBox is load-bearing.
• Fixed-size illustrations exported with explicit width/height that never scale: you can enable removeViewBox for a few saved bytes, but the savings are tiny and the risk if the asset is ever reused in a responsive context is real. Most teams should still leave it off.
• Projects wanting smaller files: the better lever is usually removeDimensions, which removes width/height while keeping viewBox — the opposite trade-off, and the scaling-safe one.

Verifying your setup

Confirm the version and the actual output rather than trusting the config:

npx svgo --version
npx svgo input.svg -o - | grep -o 'viewBox="[^"]*"'

If the viewBox survives optimization, the plugin is off. If it disappears, check your svgo.config.js for an explicit removeViewBox entry or a v2-era preset override. Also grep your config for preset-default overrides — a common migration bug is copying a v2 config that re-enables plugins v3 removed from the preset.

Safest migration approach

Start from the v3/v4 default preset with no overrides, run it against a representative sample of your SVGs, and diff the rendered output (a visual regression tool or even side-by-side browser screenshots). Only opt into removeViewBox if you can prove every consumer of those assets supplies dimensions. When in doubt, keep the viewBox — it costs a handful of bytes and prevents an entire class of scaling bugs.