The SVG Path Data Format, Explained (M, L, C, Q, A, Z)

If you've opened a <path d="..."> string and had no idea what you were looking at, here's the short version: it's a tiny drawing language. A pen moves around a coordinate space, and each letter in the string is an instruction telling it what to do next.

TL;DR

• M/m moves the pen, L/l draws a straight line, C/c and Q/q draw bezier curves, A/a draws an arc, Z/z closes the shape.
• Uppercase is absolute coordinates, lowercase is relative to the pen's current position.
• A visual path editor drags the exact same numbers you'd type by hand, it just shows you the curve instead of making you compute it.

Reading a path string

<path d="M10 10 L90 10 L90 90 Z" />

Broken down: move to (10, 10), draw a line to (90, 10), draw a line to (90, 90), close the path back to the start. That's a right triangle. Every path, no matter how complex, is this same pattern: a command letter followed by however many numbers that command needs, repeated.

The command set

Command	Name	What it takes
M / m	Move to	x, y
L / l	Line to	x, y
C / c	Cubic bezier	control1 x/y, control2 x/y, end x/y
Q / q	Quadratic bezier	control x/y, end x/y
A / a	Arc	rx, ry, rotation, large-arc-flag, sweep-flag, end x/y
Z / z	Close path	none

C and Q are both bezier curves, the difference is one control point (Q) vs two (C). Two control points give you more independent influence over each end of the curve; one control point gives you a simpler, more symmetric curve. There are also shorthand continuations (S/s, T/t) for chaining smooth curves without repeating a control point, but the six above are what you'll hit constantly.

A is the one people avoid writing by hand. Six parameters, two of which are flags (0 or 1) that determine which of four possible arcs you get for the same radii and endpoints. Flip one and you're not slightly off, you're on the opposite side of the ellipse.

Absolute vs relative is the part that bites

Every command above has an uppercase and lowercase form, and it's not cosmetic:

<!-- absolute: go to (90, 10) -->
<path d="M0 0 L90 10" />

<!-- relative: go 90 right, 10 down, from wherever the pen is -->
<path d="M0 0 l90 10" />

In this example both produce the same triangle, because the pen starts at the origin. They stop agreeing the moment you edit one segment in the middle of a longer relative path: every command after your edit is relative to a starting point that just moved, so the rest of the shape shifts with it. This is the single most common cause of "I changed one line and now the whole icon is wrong" when hand-editing SVG.

Why this gets painful fast

None of the commands above are individually hard. What breaks down is scale. A real icon or illustration is often one unbroken string with dozens of commands, no line breaks, no comments, and bezier control points that don't even sit on the visible curve, they pull it from outside. Reading four numbers and predicting the resulting curve shape in your head is not something most people can do reliably, so editing path data by hand usually turns into: change a number, re-render, squint, change it again.

What a visual editor is actually doing

Worth being precise here, since it's easy to assume there's something clever happening under the hood. There isn't. A path editor renders two things you can drag:

• Anchor points: the actual M/L/curve-endpoint coordinates in the string.
• Control handles: the control points belonging to C and Q commands, shown as draggable lines coming off an anchor.

Drag an anchor, you change where a segment starts or ends. Drag a handle, you change the curvature of the segment it belongs to, without touching the anchor. Every drag is a rewrite of the same numbers you'd otherwise be typing into the d string yourself. The editor's only job is closing the loop between "I changed a number" and "here's what that number now looks like," instantly, instead of making you simulate it.

Gotchas worth knowing before you debug one of these

• Z draws a line back to the start. An unexpected extra segment in a shape is often just Z doing exactly that.
• Arc flags (large-arc-flag, sweep-flag) are booleans, not tuning knobs. Wrong flag, wrong side of the ellipse, not a small deviation.
• Editing inside a relative-coordinate path shifts everything downstream of the edit. If you're scripting path transformations, absolute coordinates are usually safer to reason about.
• Aggressively rounding coordinates to shrink file size can leave visible seams where two paths are supposed to meet exactly.

If you'd rather drag than compute

For small, deliberate edits, working in the raw d string is fine once you know the command set. For anything with more curves than you can hold in your head, dragging nodes and watching the render update is faster than mentally running the bezier math.

SVG Lab is a free, no-install browser editor with real node and bezier handle editing on top of the raw path data, plus fill and stroke color editing. Not the only way to do this, just one option if you want to see the curve instead of computing it.