An SVG path editor is a tool that lets you change the shape of a path by dragging anchor points and bezier handles instead of typing coordinates by hand. The visual editor and the raw path data describe the exact same shape, just in two different representations of it.
What's actually inside a path's d attribute
The d attribute on a <path> element is a string of instructions, a small drawing language. Something like this:
<path d="M10 10 L90 10 L90 90 Z" />Each letter is a command. Each number after it is a coordinate or parameter that command consumes. Read left to right, the renderer executes each instruction in order, moving an imaginary pen around the coordinate space and drawing as it goes.
The commands that actually matter
- M / m, move to. Picks up the pen and puts it down at a coordinate without drawing anything.
- L / l, line to. Draws a straight line from the current point to the new one.
- C / c, cubic bezier curve. Takes two control points and an end point, three coordinate pairs total.
- Q / q, quadratic bezier curve. Same idea as C, but with a single control point instead of two, which produces a gentler curve.
- A / a, arc. Draws part of an ellipse, defined by two radii, a rotation angle, two flags, and an end point. The fiddliest command to write by hand.
- Z / z, close path. Draws a straight line back to the path's starting point and marks the shape closed.
There are shorthand variants too (S/s and T/t, for continuing a bezier curve smoothly), but M, L, C, Q, A, and Z cover what you'll actually run into in practice.
Uppercase vs lowercase: absolute vs relative
This is the detail that trips people up first. Every command has two forms, uppercase and lowercase, and they mean different things.
Uppercase commands use absolute coordinates: go to this exact point in the SVG's coordinate space. Lowercase commands use relative coordinates: move this far from wherever the pen currently is.
L 90 10 means "draw a line to the point (90, 10)." l 90 10 means "draw a line 90 units right and 10 units down from wherever the pen already is." Mixing the two without carefully tracking pen position is the most common source of "why did my shape jump" bugs when editing path data directly.
Why hand-editing path data is painful
None of the individual commands are hard to understand on their own. The pain shows up at scale. A real path, a logo, an icon, a hand-drawn illustration, can have dozens or hundreds of commands strung together in one long string with no line breaks and no comments. Move one anchor point and you're not editing one isolated value: you're recalculating a coordinate that other commands may be relative to, in a string that gives you no visual feedback about what changed until you re-render it.
Bezier curves make this worse. A C command's two control points don't sit on the curve itself, they pull the curve toward them from outside it, and the relationship between "these four numbers" and "this is the resulting curve shape" is not something most people can hold in their head reliably. You end up in an edit, re-render, squint, edit again loop, which is slow even for small changes.
What a visual path editor actually manipulates
This is worth being precise about, because it's easy to assume a path editor is doing something clever behind the scenes. It isn't. It's manipulating exactly the same data as the raw d string, just represented as objects you can see and drag.
Anchor points are the actual coordinates in the path: the M, L, and curve endpoint values. Control handles are the control points that belong to bezier curves (C and Q), usually shown as lines sticking out of an anchor that you drag to bend the curve.
Drag an anchor point and you're changing where a straight segment starts or ends. Drag a control handle and you're changing the curvature of the segment attached to it, without moving the anchor itself. Under the hood, every drag is just rewriting numbers in the d string. The editor's entire value is showing you the shape those numbers produce in real time, instead of making you simulate it mentally.
A few practical gotchas
- Z snaps back. Closing a path with
Zdraws a line from the last point straight back to the first. If a shape has an unwanted extra segment, check whetherZis the cause. - Arc flags are unforgiving. The
Acommand takes two radii, a rotation angle, and two boolean flags (large-arc and sweep) before the end coordinate. Getting a flag wrong doesn't produce a slightly-off arc, it puts you on the entirely wrong side of the ellipse. - Relative commands compound. If you insert or delete a segment in the middle of a path written with lowercase commands, everything after your edit is now relative to a different starting point than before, which can shift the rest of the shape.
- Precision matters more than it looks. Rounding coordinates to save characters can introduce visible gaps or misalignment at larger scales, especially where two paths are meant to meet exactly.
Where this leaves you
If you're comfortable reading and writing the commands above, editing path data directly is fine for small, deliberate changes. For anything with more than a handful of curves, or when you're iterating on a shape rather than making one precise fix, dragging anchor points and handles and watching the result render is a lot faster than mentally simulating bezier math.
SVG Lab is one option for doing that in the browser: it's free, no install, and has real node and bezier handle editing along with fill and stroke color editing, on top of the raw path data. Worth a look if you'd rather see the curve than compute it.