SVG path data: the d attribute explained

The path is the most powerful element in SVG, and its d attribute is where beginners tend to give up. A string like M4 20 12 4 20 20Z looks like something went wrong, so people treat icons as opaque blobs to be regenerated rather than edited. That is a shame, because the d attribute is a compact drawing language with only a handful of commands, and being able to read it turns an icon from a black box into something you can adjust in seconds. This guide walks through every command and the two or three things that make paths look more frightening than they are.

You will not come away hand-writing complex illustrations, and you should not want to. The goal is fluency: enough to read a path, understand its structure, and make a small, deliberate change.

What the d attribute is

The <path> element can draw anything the simpler shapes can, and a great deal more besides. Its d attribute, short for data, is a string of commands that move an imaginary pen around the coordinate space and draw as it goes. Each command is a letter followed by the numbers it needs, its coordinates or parameters. The pen starts wherever the first command puts it and then follows the rest in order.

Those coordinates live in the SVG's user space, so a path only makes sense alongside its viewBox, which defines that space. If the coordinate system is unclear, read the SVG viewBox first; the numbers in a d attribute are positions on exactly that grid.

Absolute versus relative commands

Every command comes in two cases, and this is the first thing that makes paths look cryptic:

• Uppercase means absolute: coordinates are measured from the SVG origin at 0,0.
• Lowercase means relative: coordinates are measured from the current pen position, the end of the previous command.

So M 10 10 moves to the fixed point 10,10, while m 10 10 moves ten units right and ten down from wherever the pen already is. Exported and optimised paths lean heavily on the relative, lowercase commands, because the numbers come out smaller and the file gets lighter. That is a big part of why an optimised path looks like dense gibberish; it is the same shape expressed in the most compact commands. The optimisation guide covers why tools do this.

The line commands

The straight-line commands are the easiest place to start:

A worked example, a triangle: <path d="M 4 20 L 12 4 L 20 20 Z"/>. The pen moves to the bottom-left corner at 4,20, draws a line up to the apex at 12,4, draws another down to the bottom-right at 20,20, and then Z closes the shape back to the start. Three points, one closed triangle. Read at that pace, even long paths are just more of the same.

The curve commands

Curves are where Bezier commands come in. A Bezier bends a line using control points that pull it, like magnets, without themselves lying on the line:

• C x1 y1 x2 y2 x y is a cubic Bezier: two control points, at x1,y1 and x2,y2, ending at x,y. This is the workhorse curve.
• S x2 y2 x y is a smooth cubic that reuses a reflection of the previous curve's control point, for continuous, flowing curves.
• Q x1 y1 x y is a quadratic Bezier: a single control point, ending at x,y. Simpler, less flexible.
• T x y is a smooth quadratic that reflects the previous control point automatically.

You almost never eyeball Bezier coordinates; a design tool sets them when you drag a curve. When reading them, the pattern is what matters: the last pair of numbers is where the curve ends, and the earlier pairs are the control points steering it there. That alone is usually enough to understand what a curve is doing.

The arc command

The arc is the command that confuses everyone, because it takes seven parameters:

A rx ry x-axis-rotation large-arc-flag sweep-flag x y

• rx, ry are the radii of the ellipse the arc is a slice of.
• x-axis-rotation rotates that ellipse.
• large-arc-flag, 0 or 1, chooses the smaller or the larger of the two possible arcs.
• sweep-flag, 0 or 1, chooses whether the arc curves clockwise or anticlockwise.
• x, y is where the arc ends.

The two flags are why an arc can suddenly bulge the wrong way: between the same two points there are four possible arcs, and the flags pick which one. If an arc looks inverted, flip a flag. In practice, for circles and rounded corners it is often easier to use a <circle> element or a Bezier than to hand-tune an arc's flags.

Holes and fill-rule

A single d attribute can contain several subpaths, each begun by its own M command. That is how one path draws a shape with a hole in it, such as the counter inside an O or the centre of a doughnut: an outer subpath and an inner one in the same path.

Which regions count as filled is decided by the fill-rule attribute, either nonzero, the default, or evenodd. With evenodd, an inner subpath cleanly punches a hole; with nonzero, the direction each subpath is drawn in affects the result. So when the counter of a letter fills in solid instead of staying open, switching fill-rule to evenodd is the usual fix.

Reading and editing paths in practice

You do not need to write complex paths by hand, and attempting it is a poor use of time; tools generate them far better. What genuinely helps is reading one well enough to make a small change, nudging a point, spotting the command that draws a stray line, or combining two icons. A few practical habits:

• Find the first M to see where the shape starts, and each Z to see where a subpath closes.
• Treat long strings of decimals as optimiser output, not something meaningful to read; the letters are still the structure.
• To change the shape, open the SVG in a vector editor and drag the nodes rather than editing numbers by hand. To change colour or size, you never touch d at all, only the fill or the viewBox.
• After any manual edit, run the file through an optimiser to tidy the precision and merge commands back down.

Read this way, path data stops being intimidating. It is a short list of pen instructions, dense only because tools compress it, and entirely legible once you know the letters.

Frequently asked questions

Want the coordinate system these numbers actually live in? See the SVG viewBox.

Paths bloated with long decimals? That is what optimising SVG files is for.