Index / Developer
SVG Path Optimizer
Shortens the d attribute of a path, then samples both the
original and the result and reports how far apart they ever get. An
optimizer you cannot check is worse than none.
Path data
Paste the contents of a
d attribute. The
surrounding <path> tag is not needed, and is ignored
if you paste it anyway.
Optimizations
This is an absolute tolerance, not a relative one.
Three places is generous inside a 24-unit viewBox and coarse inside
a 1-unit one. The deviation figure tells you which you have.
Waiting for a path
--
Saved
--
Max deviation
--
Result
--
Both paths, drawn on top of each other
grey solid: before · orange dashed: afterWhat changed
How the check works, and what it can and cannot tell you
The result is parsed again from the text you see, not carried over
from the optimizer's own state. Both paths are then flattened into
several hundred points each, and the figure above is the
Hausdorff distance between the two sets: the furthest any point on
either curve is from the nearest point on the other. It is in user units,
the same units as the path. Rounding to n places can move a point
by up to half of 10−n in each axis, so a healthy
deviation sits at or just under that.
It compares outlines, not fills. A change to the winding direction of a subpath would not show up here and would change how
Arc flags are written out separated, never packed. Packing them (
A zero-length line is kept when the next command is
Command choice is greedy, one segment at a time. Occasionally a longer choice early would let more letters be omitted later; this does not look for that, so the output is short but not provably shortest.
It compares outlines, not fills. A change to the winding direction of a subpath would not show up here and would change how
fill-rule: evenodd renders. Nothing this tool does reorders
or reverses a subpath, but that is the one thing the check does not
independently confirm.
Arc flags are written out separated, never packed. Packing them (
a1 1 0 011 1) is legal, and this tool reads it, but enough
parsers get it wrong that the two bytes are not worth it.
A zero-length line is kept when the next command is
S or T. Those take their first control point by
reflecting the previous curve's, and only when the previous command was
itself a curve — so removing the line between them silently changes
the shape.
Command choice is greedy, one segment at a time. Occasionally a longer choice early would let more letters be omitted later; this does not look for that, so the output is short but not provably shortest.