Compress SVG path data with SVGO's convertPathData, then verify the render

Path-heavy icons ship verbose coordinates

Path-heavy SVG icons often contain verbose coordinate strings. A single icon can carry dozens of absolute move-to and line-to commands, each separated by spaces and repeated across a design system. When a frontend bundles hundreds of these files, the markup itself becomes a measurable part of page weight.

The useful takeaway: run SVGO's convertPathData plugin on build-time copies of your SVG assets, not on editable source files, and compare rendered output at every target size before adopting the optimization. The plugin rewrites equivalent path data into shorter forms, but exact output depends on SVGO version and precision settings, so visual review is required.

What convertPathData rewrites

SVGO is a command-line and Node.js tool for optimizing SVG files. The convertPathData plugin operates on the d attribute of <path> elements. That attribute holds the path data, a sequence of commands such as M (move to), L (line to), H (horizontal line), V (vertical line), and Z (close path).

Depending on configuration, convertPathData can:

• Remove unnecessary whitespace between commands and coordinates
• Convert absolute commands to relative commands where shorter
• Replace L 10 0 with h 10 when the line is perfectly horizontal
• Merge consecutive commands of the same type

The geometry should remain equivalent, but the string length can shrink. Because SVG path data is text, fewer bytes mean less markup to transfer, especially when icons are inlined rather than referenced as images.

Worked example

Consider a square icon authored as:

<path d="M 0 0 L 10 0 L 10 10 Z" />

With convertPathData enabled, SVGO may rewrite that path data to:

<path d="M0 0h10v10z" />

The rewrite removes spaces, expresses the horizontal segment as h, the vertical segment as v, and uses lowercase z for close path. Do not treat this output as a contract. SVGO versions and plugin options can produce different equivalent strings, so avoid asserting a specific optimized d value in automated tests.

To try this safely, run the SVGO CLI against a copy:

# Run in your project terminal. Requires read access to the source
# and write access to the output directory.
npx svgo@latest --config svgo.config.js -i src/icons/square.svg -o dist/icons/square.svg

Placeholders:

• svgo.config.js: your SVGO configuration file
• src/icons/square.svg: original editable icon
• dist/icons/square.svg: optimized build output

Expected checks after the command runs:

• dist/icons/square.svg exists and is smaller than the source
• The d attribute changed, but viewBox and dimensions did not
• The file still opens in a browser without parse errors

Risks: overwriting source files destroys authoring history, and optimizing untrusted user-uploaded SVGs does not make them safe. SVGO is an optimizer, not a sanitizer.

Precision and the trade-off that matters

The main engineering trade-off is floatPrecision. This setting controls how many decimal places SVGO keeps when rewriting coordinates. Lower precision saves bytes but can shift curves, stroke alignment, or clipping boundaries by fractions of a pixel.

For straight icons, the difference is usually invisible. For detailed artwork with Bézier curves, non-uniform transforms, or thin strokes, aggressive rounding can move endpoints enough to change how a stroke sits on a pixel grid. A path that looked crisp at 16 pixels might blur or shift at 24 pixels after optimization.

Start with conservative settings. A minimal config might look like:

module.exports = {
  plugins: [
    {
      name: 'convertPathData',
      params: {
        floatPrecision: 3,
      },
    },
  ],
};

floatPrecision: 3 keeps three decimal places. Lower it only if visual review confirms no unacceptable change at your smallest supported display size.

Build-time verification workflow

Do not optimize once and forget. Treat SVG optimization like code: review the diff, then render the result.

1. Copy the icon directory to a build folder.
2. Run SVGO with your chosen config.
3. Compare file sizes and d attributes between original and optimized copies.
4. Render both versions at every intended display size in your target browsers.
5. Compare screenshots or overlay the renders to catch stroke, curve, or alignment changes.
6. Test a fixture set that includes straight segments, curves, transforms, strokes, and CSS-dependent classes before rolling out to the full library.

Record the installed SVGO version and configuration. Rerun the comparison after upgrades, because defaults and output details can change between releases.

Limitations:

• Already compact SVGs may gain little from path conversion.
• Transport compression such as gzip or Brotli can capture repetitive markup that byte-level path rewriting cannot.
• Path rewriting can expose rendering differences involving transforms, strokes, clipping, or non-uniform scaling.
• SVGO does not sanitize untrusted SVG.

Practical check: open the original and optimized SVG side by side at 1×, 2×, and your smallest production size. If the shapes, stroke positions, and fills match, the optimization is a candidate for the build pipeline. If anything shifts, raise floatPrecision or exclude that asset.

Closing recommendation

Enable convertPathData deliberately, optimize copies during the build, compare renders at target sizes, and adopt the smallest configuration that passes visual review. Smaller icons only help if they still look correct.