Loading Techie Utils…

SVG Path Editor & Viewer

Draw path data and read back what it contains. Free, and runs entirely in your browser — nothing you enter is uploaded, stored or sent to a server.

About SVG Path Viewer

Path data is the least readable thing in a stylesheet or an icon set: a stream of letters and numbers where the state is implicit. m is relative to wherever the last command ended, s infers its first control point by reflecting the last one, h and v carry only one number, and a command letter can be omitted entirely to repeat itself. Reading that by eye is not a skill worth acquiring.

So the path is parsed and drawn, and then written back out with everything resolved: every command absolute, every shorthand expanded, every arc converted to cubic curves. The normalised version is longer and far easier to edit by hand — move one point and nothing downstream of it shifts, which is exactly what relative commands do not give you.

The bounding box is the other reason to come here. A path whose coordinates run from 0 to 24 needs viewBox="0 0 24 24", and a path that has quietly drifted outside it is the usual explanation for an icon that looks cropped or off-centre — so the box it actually occupies, and a viewBox that would fit it, are reported outright.

Where it helps

  • Draws the path at any size, with a marker at every point, so the segment you are hunting for can be found by looking.
  • Normalises to absolute commands, which is the form you can edit by hand without everything after the change moving.
  • Reports the bounding box and a viewBox that fits it, which is the answer to most cropped-icon problems.
  • Counts the commands as written — relative against absolute — so a path's real complexity is visible.
  • Accepts a whole <path> element as well as bare d data, because that is what people copy.
  • Runs entirely in your browser.

Limits

  • One path at a time. A whole SVG with groups, transforms and several shapes is not composited here.
  • Arcs are converted to cubic curves, so the normalised output is not byte-for-byte equivalent to the input — it draws the same and is longer.
  • The bounding box includes control points, so a curve that bulges less than its handles suggest reports a slightly generous box.
  • Nothing is optimised. Removing redundant points or shortening numbers is a different job, and a dedicated optimiser will beat this at it.
  • Transforms on the element are ignored: only the d attribute is read.

Frequently asked questions

Why is the output longer than what I pasted?

Because every shorthand has been expanded. Relative commands become absolute, h and v become L, smooth curves get their inferred control point written out, and arcs become cubic curves. That is the form that is editable by hand; keep the original if you are optimising for bytes.

What is a subpath?

Everything from one M to the next. A path with two subpaths draws two shapes, which is how a hole is made — the inner subpath is cut out of the outer one by the fill rule rather than drawn as a separate element.

My icon looks cropped. What is wrong?

Almost always that the viewBox does not match the coordinates. Compare the bounding box reported here with the viewBox on your <svg>: if the path runs to 26 and the box stops at 24, the last two units are cut off.

Can I convert this path into a font glyph?

Yes — the Icon Font Generator takes SVG paths and builds a web font from them, and it uses the same normalisation you see here.

Related tools

More Web Development tools