What the `d` attribute is saying

Open it in a text editor

Right-click any SVG, open it with Notepad, TextEdit or nano, and look. There is no magic in there. There is a list of instructions.

<path d="M 20,80 C 20,20 80,20 80,80 Z" fill="#1d4ed8"/>

Read it out loud. Move the pen to 20,80. Draw a Cubic curve whose first handle points to 20,20, whose second handle points to 80,20, ending at 80,80. Z closes the path back to the start.

That is the whole vocabulary you need, and there are only a handful of commands:

• M x,y: move without drawing. Starts a new subpath.
• L x,y: straight line to a point. H x and V y are the horizontal and vertical shorthands.
• C x1,y1 x2,y2 x,y: cubic Bézier: two handle positions, then the end point. This is by far the most common.
• S x2,y2 x,y: smooth cubic. Reuses the previous curve’s outgoing handle, mirrored. This is how exporters compress a smooth run of curves.
• Q and T: quadratic Bézier, one handle. TrueType fonts are built from these; PostScript and SVG artwork mostly is not.
• A rx,ry rot large-arc sweep x,y: elliptical arc. Rarely written by hand, common in output from charting libraries.
• Z: close the subpath.

A capital letter means absolute coordinates. A lowercase letter means relative to where the pen already is. l 10,0 means “ten units right of here”. Exporters use lowercase because the numbers come out shorter.

The coordinate frame

Two attributes decide what those numbers mean.

<svg viewBox="0 0 100 100" width="40mm" height="40mm">

viewBox sets the internal coordinate system: this drawing is 100 units across. width and height say how large to render it. Change the width to 400mm and nothing inside the file changes: the same 100 units are stretched over a larger area. This is the whole of resolution independence, in one attribute.

If width and height are missing, browsers treat them as 100% and scale the viewBox to fit whatever box the SVG sits in, while converters such as rsvg-convert take the viewBox numbers as pixels, at 96 to the inch. That 96-to-the-inch default is the cause of a great deal of confusion, and it is the next lesson.

Why two identical-looking logos differ by 8,000×

Export the same mark two ways and you will see something like this:

play-drawn.svg       240 bytes    3 path elements
play-traced.svg    1,912,406 bytes  412 path elements

Three things inflate a file, and all three are visible in the text:

1. Node count. A traced logo has hundreds of anchor points where a drawn one has eight. Every anchor is six numbers.
2. Decimal precision. Illustrator and Inkscape happily write 47.238471950000003. Fifteen significant figures on a drawing that will be cut at half-millimetre accuracy is sixty bytes of nothing.
3. Embedded rasters. An <image xlink:href="data:image/png;base64,..."> means somebody placed a photograph inside what they called a vector file. This is the single most common reason a “vector logo” fails when the printer enlarges it.

Search the file for base64. If you find it, you do not have vector artwork.

Cleaning up, free

svgo and scour both strip precision, merge paths and remove editor metadata:

npx svgo --precision=2 logo.svg -o logo.min.svg

Two decimal places on a 100-unit viewBox is accuracy to a hundredth of a unit, one ten-thousandth of the drawing’s width: on the 40 mm logo above, four micrometres. Nothing you print can hold more.

The part nobody tells you: batch editing

Because it is text, you can do things no menu offers. A client changes their brand blue and you have forty icons:

sed -i 's/#1d4ed8/#0f766e/g' icons/*.svg

Forty files, one second, no application open. You can also grep an entire folder for base64 to find the fake vectors, or for font-family to find the files where somebody forgot to outline the type.

This is not a trick for programmers. It is the single most useful thing about the format, and it is why SVG, unlike the AI, CDR and PDF files most design tools save, diffs sensibly in version control: you can see, line by line, what changed between two versions of a drawing.

Watch out for transform

A path can sit inside nested groups, each with its own transform="translate(...) scale(...) rotate(...)". The numbers in d are then not the numbers on your ruler. If coordinates look wrong, look upward at the groups. Most editors have an “ungroup and bake transforms” step; in Inkscape, Edit ▸ Preferences ▸ Behaviour ▸ Transforms ▸ Store transformation: Optimized pushes transforms down into the path data where you can read them.