Choose an SVG, or paste its code, and it is laid out one element to a line, indented by how deeply each is nested. Nothing but white space changes, and the page draws the file before and after to prove the picture is the same.

Free, no account. The file is read by code running in your browser. It is not uploaded, and nothing about it is stored.

How to format an SVG

Choose your SVG, drop it on the box, or paste SVG code. The formatted code appears at once.
Pick the indent: two spaces, four spaces or tabs.
Choose whether a long tag gets one attribute to a line, and whether path data is split one command to a line.
Read the line under the code: it says whether the two pictures match pixel for pixel. Then download the SVG or copy the code.

What it changes

White space, and only where white space means nothing: between one element and the next, and between the attributes inside a tag. Each element goes on a line of its own, indented one step further than the element that holds it. Comments, processing instructions and the DOCTYPE get lines of their own as well. The file ends with one line break.

The sample on this page is a small drawing saved the way an optimiser leaves it: 869 bytes on a single line. Formatted with two spaces it is 23 lines and 967 bytes. One tag in it would run past 100 characters, so its five attributes are put one to a line; with “All on one line” the file is 18 lines. With “One command a line” each path is opened out as well, and the file is 39 lines.

A tag counts as long when it would run past 100 characters, indent included, and has more than one attribute. Path data is only split where it parses, and it is split at the command letters: the numbers, and the commas and spaces between them, are not rewritten.

What it never touches

Text. Every <text> element is kept whole, from its opening tag to its closing one, character for character. A space or a line break between two <tspan> elements is drawn as a space, so re-indenting there would move the words.
Style sheets and scripts. <style> and <script> are kept whole, CDATA and all. So are <title>, <desc> and <foreignObject>.
Any element with words between its tags, such as the titles inside an editor’s metadata. Its contents are written back as they were.
Anything under xml:space="preserve". That attribute says white space is part of the content. Illustrator puts it on the outer <svg>, which covers the whole drawing, so in such a file only the outer tag is laid out and everything inside comes back as it went in, with a note. Only text is drawn differently because of it, so the page then offers “Re-indent between elements”, which lays out everything else and still keeps each <text> whole.
Comments, CDATA, processing instructions and the DOCTYPE, entities included. Their insides are never re-indented.
Names, values and quotes. Attributes keep their order, their values and the quote marks they were written with. Numbers are not rounded and colours are not rewritten.
Empty elements. <g></g> stays as it is and so does a group holding nothing but a space, because a style sheet can tell the two apart with :empty.
The byte order mark and the line endings. A file that starts with a byte order mark keeps it, and a file with Windows line endings gets Windows line endings.

How the picture is checked

The page draws the file you gave and the formatted one at the same size, 800 pixels on the longer side, and compares every pixel. The line under the code says “identical, pixel for pixel” when not one differs. It is the same check the SVG optimizer runs, and for the same reason: a tool that rewrites a file should show that the drawing survived.

Formatting is the optimizer’s opposite. Format a file and then optimise it, and you get byte for byte what optimising the original gives. The one exception is editor data that the optimizer has to keep, as it does in a file with a script: it keeps that data in whatever layout it finds, so the two results then differ in white space there and nowhere else.

What to know

The file gets larger. Indents and line breaks are bytes: the sample grows by about a tenth. Format a file to read it, edit it or compare two versions line by line, and optimise it again before it goes on a website.
It does not sort or tidy. Attributes are not put in order, unused ids are not removed, and <rect></rect> is not shortened to <rect/>. What the file says stays what it says.
A file that does not parse is refused. There is no safe way to lay out XML with a tag left open. The SVG validator says where the fault is.

Questions

Does formatting change how the SVG looks?

No. Only white space between elements and between attributes changes, which no renderer draws. The page proves it for your file by drawing both versions and comparing them pixel by pixel.

Why is my text still on one long line?

Because inside <text> a line break counts as a space, and a space is drawn. Breaking the line there could move the words, so each text element is written back exactly as it came.

My Illustrator file came back almost unchanged. Why?

Its outer element says xml:space="preserve", which tells every program that white space in the file matters. Press “Re-indent between elements” under the code: everything except the text is laid out, and the pixel check confirms the picture is the same.

Tabs or spaces?

It makes no difference to the picture. Two spaces keeps deeply nested files narrow, which suits SVG. Use tabs if your editor or your team’s style asks for them.

How do I make the file small again?

Run it through the SVG optimizer, which takes the indents and line breaks out again along with everything else a renderer does not need.

SVG formatter