Does SVGO’s default enable of removeViewBox break repeatable SVG optimization?

Answer

The removeViewBox plugin being enabled by default in SVGO can indeed introduce non-determinism into repeatable SVG optimization workflows, particularly for responsive SVGs. The core issue isn't whether the plugin itself works—it functions as designed—but whether its default state aligns with the goal of predictable, environment-consistent output.

Confirmed Behavior

In SVGO v2.x and later, the removeViewBox plugin is enabled by default. It removes the viewBox attribute when both width and height are present, under the assumption that the SVG is not responsive. This is documented behavior, and the plugin logic is straightforward: if an SVG has explicit dimensions and no need for scaling, the viewBox can be safely stripped to reduce file size.

For teams committing an SVGO configuration file to version control, the default setting matters because it determines the baseline optimization behavior. If the config doesn't explicitly set removeViewBox, the plugin remains active, and its behavior becomes part of the optimization contract across environments.

Impact on Repeatable Optimization

The risk to repeatability arises in two scenarios:

• Responsive SVGs: If an SVG relies on viewBox for scaling (e.g., inline SVGs in HTML that must adapt to container size), enabling removeViewBox by default will strip it, causing visual breakage that may not surface in all environments.
• Version drift: If a team upgrades SVGO without updating their config, a change in default behavior (if any) could silently alter output.

However, SVGO's defaults have remained stable across recent versions, so the primary concern is correctness, not consistency across SVGO versions.

Guidance for Teams

To ensure repeatable optimization, teams should:

1. Explicitly configure removeViewBox: Add plugins: [{ removeViewBox: false }] to your .svgorc.js if your SVGs are responsive or if you want to preserve viewBox for future-proofing.
2. Test with representative assets: Run SVGO on a sample of your SVGs and verify that viewBox is preserved when expected.
3. Document the decision: Include a comment in your config explaining why removeViewBox is set to false (or true), so future maintainers understand the rationale.

Verification Steps

Run the following to inspect current defaults:

npx svgo --show-plugins | grep removeViewBox

This will show whether the plugin is enabled by default in your current SVGO version. Then test with a responsive SVG:

npx svgo input.svg -o output.svg && cat output.svg | grep viewBox

If viewBox is missing and your SVG is responsive, you've confirmed the issue.

Conclusion

The removeViewBox default doesn't inherently break repeatability—it provides a sensible optimization for non-responsive SVGs. The problem is that teams may not realize it's active, leading to inconsistent visual results. The solution is explicit configuration, not disabling the plugin universally. For maximum safety in shared workflows, set removeViewBox: false and rely on other plugins for size optimization.