SVG Path Parser
Break down an SVG path d= attribute into commands.
Overview
The SVG Path Parser breaks down the d= attribute of an SVG <path> element into its individual commands, with each one decoded into a human-readable line: the command letter, its parameters, and the implied current-point movement. Paste a path string and the parser walks it from start to finish, exposing every quirk of the SVG path mini-language.
It is the right tool when debugging an icon that renders incorrectly, learning how Q and T curves chain, comparing two paths produced by different drawing programs, or building tooling that needs to interpret SVG path commands. Designers and frontend developers reach for it whenever a path "just doesn't look right".
How it works
SVG path data is a sequence of single-letter commands followed by their numeric parameters. The grammar supports absolute (uppercase) and relative (lowercase) forms: M moves to an absolute coordinate, m moves by an offset. The full alphabet covers M/m (move), L/l (line), H/h/V/v (horizontal/vertical), C/c/S/s (cubic Bezier and smooth continuation), Q/q/T/t (quadratic and smooth continuation), A/a (elliptical arc) and Z/z (close path).
The parser tokenises the string into commands and floats, tracks the "current point" after each step, and emits a structured listing. Implicit commands — where subsequent coordinate pairs after an M are treated as L line-to commands — are made explicit so the breakdown matches what the renderer actually does.
Examples
Input: M10 10 L50 10 L50 50 Z
Output:
M 10 10 → moveTo (10,10), current=(10,10)
L 50 10 → lineTo (50,10), current=(50,10)
L 50 50 → lineTo (50,50), current=(50,50)
Z → closePath → (50,50) to (10,10)
Input: M0 0 q10 0 20 20 t20 0
Output:
M 0 0 → moveTo
q 10 0 20 20 → relative quadratic Bezier
t 20 0 → smooth quadratic continuation
FAQ
What does the T command actually do?
T continues a quadratic curve by reflecting the previous control point through the current end-point. It only makes sense after a Q or another T; before any quadratic, it behaves as if the control point sits on the current point.
Why are some coordinates negative when I see no values that small in my path?
Lowercase commands are relative — the parser converts them to absolute internally so you can see the running current point, but the raw values are deltas in the source.
How are arc commands parsed?
A rx ry x-axis-rotation large-arc-flag sweep-flag x y — seven parameters per arc. The parser surfaces each one with its meaning.
Does it validate the path?
It flags syntactic errors (unknown commands, wrong parameter counts) but does not check whether the path is geometrically reasonable.
Can I round-trip the listing back into a path?
The structured output can be re-serialised by reversing the listing — useful for tools that want to rewrite or transform paths programmatically.