SVG Formatter

How it works

The file is parsed with the browser's own DOMParser and printed back out — pretty-printed with two-space indents and one element per line, or flattened to a single line with the whitespace between tags removed. Either way it is the same document: the same elements, the same attributes in the same order, the same text content. Only the whitespace between elements changes, which is why the formatter can promise a lossless round trip where an optimizer cannot. Both outputs are computed at once and their byte counts shown side by side, and everything happens in your browser — the file is never uploaded.

Text that matters is left alone. The content of <text>, <title> and <style> elements is real data, not layout, so the single-line mode only collapses runs of whitespace that sit purely between tags — the classic export artefact — and never touches whitespace inside a text node that has actual content.

What the pretty-printer does, exactly

Every element opens on its own line, indented two spaces per level of nesting. An element with no children is written self-closing — <circle … /> — and an element whose only child is a piece of text keeps it inline, so <title>Bolt badge</title> stays one readable line instead of three. Comments survive in place, because a comment in a hand-maintained file is usually there for a reason. Attribute order is preserved exactly as parsed, and attribute values are re-escaped consistently, so two files formatted here diff cleanly against each other. What does not survive is the XML prolog: the output starts at <svg>, because the <?xml … ?> declaration and DOCTYPE are optional noise for an SVG served with the right content type.

The single-line direction

Single line is for embedding, not for saving bytes. Markup that is about to sit inside a JSON string, a database field, an HTML attribute or a CMS text box breaks — or bloats into \n escapes — the moment it contains literal newlines, and one flat line sidesteps all of it. The transformation is exactly one rule: whitespace that sits entirely between a closing and an opening tag is removed, because it is layout; whitespace inside a text node that has real content is data and is kept. The byte counts under the style switch make the honest point that this saves little — indentation is a few percent of a typical file. For actual weight reduction — dropped metadata, rounded coordinates — you want the optimizer, which minifies as its final step anyway.

When to use it

Exported SVGs are written for machines: Illustrator and Figma emit everything on one line, Inkscape nests groups ten levels deep with a tangle of namespaced attributes. Before you can review a file in a pull request, diff two versions of an icon, or hand-fix one attribute, you need markup a person can read — that is the pretty-print direction, and because the document is guaranteed unchanged, formatting before committing costs nothing but readability gained. It is also the fastest way to see what a file actually contains: one minute of scrolling indented markup answers "why is this icon 30 KB" faster than any inspector. The single-line direction is the opposite move, covered above. Either result can be copied, downloaded, or applied to the shared document and carried into the editor.

Formatter or optimizer?

They answer different questions. The formatter changes how the markup looks and guarantees the document is untouched — nothing removed, nothing rounded. The optimizer changes what the markup contains: it strips editor metadata, drops unreferenced ids, collapses redundant groups and rounds coordinates, each pass switchable, and it can minify as its final step. If the goal is a smaller file, use the optimizer; if the goal is readable or embeddable markup with zero risk of a visual change, use this. And if the question is not how the file looks but whether something is wrong with it, the viewer runs the checks.

Common problems

• Nothing appears in the output. The markup does not parse as XML — an unclosed tag, a stray ampersand, mismatched quotes. A formatter needs a parsed document to print. Paste the markup into the viewer's validation box to get the parser's error with its line number, fix that, and format again.
• The pretty file is bigger than the input. Correct and expected — indentation is added whitespace. Readability and weight pull in opposite directions; format for people, minify (or better, gzip) for the wire.
• Multi-line text shifted slightly. Pretty-printing puts each <tspan> on its own indented line, and SVG renders the line break between them as a space. For files with carefully spaced text spans, use single-line mode, which introduces no whitespace at all.
• The XML declaration is gone. By design — the output begins at the root element. An SVG served as image/svg+xml or inlined into HTML has no use for the prolog; add one back manually if a legacy consumer insists.