How to svg path precision: why less is almost always more
- Step 1Inspect the raw path data — Open the SVG in a text editor and read the
dattribute of a<path>. Count the digits after the decimal on a few coordinates — Figma and Illustrator commonly show 6–12 significant figures. That is your starting precision. - Step 2Work out your display size — Note the viewBox dimensions and the size you actually render the asset at. A coordinate error of 0.5 user-units in a
0 0 24 24viewBox shown at 24px is a 0.5px error; the same error in a0 0 1200 600viewBox shown at 1200px is invisible. Precision is relative to coordinate scale. - Step 3Generate candidate precisions — Run the file through the Precision Tuner at 0, 1, 2, and 3 decimal places. The slider steps in whole numbers; each run produces a downloadable
{name}-tuned.svgand a Saved percentage. - Step 4Compare at real display size, not zoomed in — View each version at the size you actually ship — 16–48px for icons, full width for hero art. Distortion that is obvious at 800% zoom is usually invisible at 24px. Judge at the size users see.
- Step 5Pick the lowest precision that still looks right — The right value is the smallest decimal-places setting where the shape is still correct at display size. For most icon sets that is 1; for illustrations, 2. Reserve 0 for plainly geometric shapes.
- Step 6Apply consistently across the asset set — Once you know the safe precision for a given asset type, apply the same value to the whole icon library so file sizes and rendering stay uniform. Follow with the minifier for the structural bytes.
Precision vs pixel error at display size
Approximate worst-case coordinate error from rounding, and what it means in pixels at common display sizes. Error is relative to the path's coordinate scale, so the viewBox matters as much as the decimal count.
| Decimal places | Max rounding error (user units) | ≈ pixel error at 24px (viewBox 0 0 24 24) | Verdict |
|---|---|---|---|
| 0 | ±0.5 | ±0.5px | Visible on curves; fine for whole-unit geometric icons |
| 1 | ±0.05 | ±0.05px | Imperceptible at 16–64px — the icon sweet spot |
| 2 (default) | ±0.005 | ±0.005px | Safe for logos and illustrations at any normal size |
| 3 | ±0.0005 | ±0.0005px | Overkill for screens; useful only when zoomed far past 100% |
| 4 (max) | ±0.00005 | ±0.00005px | Effectively original fidelity; minimal byte saving |
Where the precision comes from
Why exporters emit far more digits than any display can use.
| Source | Why it over-emits | Typical digits seen |
|---|---|---|
| Figma | Vector math runs in double-precision floats; export writes the raw result without rounding | 6–12 significant figures |
| Illustrator | High internal precision plus transform composition (rotate/scale bakes in long decimals) | 5–8 decimal places |
| Auto-traced output | Tracers fit many control points to pixel data, each with full float precision | Long decimals on every node |
| Sketch / Affinity | Similar float pipelines; precision depends on export settings | 4–8 decimal places |
Cookbook
How precision plays out in practice — the same coordinate seen at different rounding levels, and what survives.
One coordinate, four precisions
The square root of 2 over 2 — a value that appears constantly in rotated/diagonal paths — rounded by the tuner at each slider position.
Original: 0.70710678118 0 places → 1 1 place → 0.7 2 places → 0.71 3 places → 0.707 4 places → 0.7071 At 24px on screen, 0.71 and 0.70710678118 are the same pixel.
Float noise that should have been a clean integer
Figma's arithmetic turns what was meant to be 12 into 12.000039062500002. Rounding restores the intended value with zero visible change.
Before: M12.000039062500002 4.99998 L24 4.99998 After (1 place): M12 5 L24 5 The original was never meant to be 12.0000390625 — it is floating-point residue, not design intent.
Why viewBox scale changes the answer
The same absolute coordinate error feels very different depending on the coordinate system. This is why 'how many decimals' has no universal answer.
Icon (viewBox 0 0 24 24, shown 24px): rounding to 0 places = up to 0.5px error → can show on curves Hero (viewBox 0 0 1200 600, shown 1200px): rounding to 0 places = up to 0.5px error too, BUT relative to 1200px it is invisible. Same setting, opposite outcome — judge against the scale.
Precision rounding vs node simplification
Two different optimisations people confuse. Rounding keeps every point; simplification deletes points. They compose well but are not interchangeable.
Precision tuner (this tool): M8.4001 6.1002 L15.6003 12.0 L8.4001 17.9 (3 points) → 1 place → M8.4 6.1 L15.6 12 L8.4 17.9 (still 3 points) Path simplifier (RDP): a 40-point hand-drawn curve → 12 points → fewer nodes, slight shape change at high tolerance
Picking precision per asset type
A pragmatic policy you can apply across a design system without re-judging every file.
Geometric UI icons (24px) → 0 or 1 place Brand logos → 2 places Detailed illustrations → 2 places Large hero / background art → 2–3 places Then: minify → estimate compressed size.
Edge cases and what actually happens
Curve control points rounded too hard
Over-simplified lookBézier C/S/Q/T control points sit off the visible path; rounding them to 0 places can shift the curve's bulge enough to see a kink, even though the on-path anchors look fine. The tuner does not refit curves — it only rounds. Keep curve-heavy art at 1–2 places.
Tiny viewBox makes low precision aggressive
Scale-relativeIn a 0 0 1 1 normalised viewBox, 1 decimal place is a 10% coordinate step — extremely coarse. The same slider value is gentle in a 0 0 1000 1000 viewBox. Always reason about precision relative to the viewBox scale, not in the abstract.
Already-rounded file, no change
No-opIf a coordinate already has fewer decimals than the slider value, it is left alone and Saved shows 0%. Rounding 12 to 2 places is still 12. There is nothing to remove, which is the correct result.
viewBox precision unchanged by design
PreservedThe tuner never rounds viewBox, so a precise viewBox like 0 0 23.999998 23.999998 stays exactly. This is deliberate — editing the viewBox can rescale the whole graphic. Treat viewBox cleanup as a separate, manual step.
transform numbers stay verbose
By designtransform="matrix(...)" or translate(...) values are outside the rounding scope. If your bloat lives in baked transforms, flatten them in the design tool before export — the tuner only rounds path and shape coordinates.
Scientific notation in coordinates
Left as-isA coordinate written as 1.2e-5 keeps its exponent — the rounder operates on the mantissa and leaves the e-5 attached, so it is not normalised to a plain decimal. Rare in design-tool output, but if present it will not be cleaned up here.
Expecting a huge file drop from precision alone
Partial winCoordinate digits are only one source of bytes. Tag names, attributes, colours, and metadata often dominate. Precision tuning is one lever; combine it with the minifier, metadata scrubber, and unused-defs purger.
Confusing precision with quality loss
ExpectedAt sensible precision, rounding is visually lossless — the error is far below one pixel. It only looks like quality loss when you over-round (0 places on curves) or zoom far past the asset's real display size. Judge at shipping size.
Frequently asked questions
Why does Figma export so many decimal places?
Figma performs all vector calculations in double-precision floating point and writes the raw result at export rather than rounding it. This preserves internal fidelity but produces verbose coordinates like 12.000039062500002 that carry far more precision than any display can render.
At what point does rounding become visible?
When the rounding error exceeds roughly 0.5px in any coordinate at your actual display size. For a 24px icon in a 0 0 24 24 viewBox, 1 decimal place gives ±0.05px — about a tenth of the perceptible threshold — so it is invisible. The viewBox scale matters as much as the decimal count.
Is precision reduction the same as path simplification?
No. Precision reduction rounds the existing coordinates and removes no points, so the shape is preserved. Path simplification (the Ramer–Douglas–Peucker method in the path simplifier) deletes whole control points to cut node count. One is lossless-looking cleanup; the other deliberately changes geometry.
Does reduced precision affect SVG animation?
Not for typical web animation. CSS keyframe and SMIL animations interpolate between values, and at 1–2 decimal places the motion is visually identical to 8-decimal originals. The tuner also leaves transform and CSS untouched, so transform-driven animation values are unaffected entirely.
Why is there no universal 'right' number of decimals?
Because precision is relative to coordinate scale. The same decimal-places value is gentle in a 1200-unit viewBox and aggressive in a 1-unit one. Reason about the worst-case pixel error at your real display size, then pick the lowest precision that stays under one pixel.
Does the tuner round my viewBox or transforms?
No. It rounds only the d path data and the numeric attributes cx cy x y r rx ry x1 y1 x2 y2 width height points. viewBox, transform, gradient offsets, and CSS in a style block are preserved exactly — those affect the coordinate system or live outside the scope on purpose.
Will lower precision compress better with gzip?
Generally yes — fewer distinct, shorter number tokens means lower text entropy, which gzip and brotli exploit. The exact win varies by file. Check the actual compressed payload with the compression estimator after tuning and minifying.
Is 8 decimals ever actually needed?
Almost never for web display. Eight decimals of precision in a typical viewBox is well below atomic-scale relative error — far beyond any screen. The only places ultra-high precision matters are non-display pipelines like CNC or plotting, which are not the SVG-on-the-web use case this tool targets.
What happens to a coordinate that is already an integer?
Nothing — rounding an integer to any number of places returns the same integer. The tuner is safe to run on partially-cleaned files; only over-precise numbers change, and clean files come out byte-identical with 0% saved.
Should I round before or after simplifying?
Either order works, but a common pipeline is simplify first (to cut node count) then tune precision (to clean the survivors), then minify. The simplifier changes which points exist; the tuner just tidies the numbers on whatever points remain.
Is anything uploaded when I test precision levels?
No. The Precision Tuner processes entirely in your browser (or your own paired runner on Pro+), so testing several decimal settings never sends the SVG anywhere. The result panel shows a '0 bytes uploaded' badge.
How do I apply one precision policy across a whole icon set?
Decide the safe value per asset type using this page's table, then apply it uniformly. The UI handles one file at a time; for a whole library, drive the same decimalPlaces value through automation as described in the batch precision guide.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.