XML Formatter

Pretty-print or minify XML documents.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

The XML Formatter re-indents a document so each element sits on its own line at its own depth, checks that it parses before doing so, and can run the other way to strip every space between tags back out.

How to use it

1Paste the document into the XML Input box — a SOAP envelope, an RSS item, a build config.
2Choose 2 or 4 spaces of indent, then press Format. Nothing happens while you type; the buttons do the work.
3Press Minify instead to collapse the whitespace between tags into a single line.
4If the paste is refused, read the line and column in the red text — the browser's own parser reporting where the document stopped being well-formed.

Example

Input: <note><to>Tove</to><from>Jani</from></note>
Output: <note> <to>Tove</to> <from>Jani</from> </note>

An element whose only content is text keeps its closing tag on the same line; only nesting earns an indent. Mixed content is where that rule bites: Hello bold world comes back as five lines, and the spaces that separated those words are now line breaks — harmless in data XML, wrong for anything read as prose. Minify has the opposite bias, removing only whitespace between a > and a <, so spacing inside a text node survives untouched. Comments, CDATA sections, namespace prefixes and self-closing tags all pass through as they were. Two things stop the parse before any of that begins, both ordinary in pasted material: a bare & — it has to be written & — and an HTML void element such as with no closing slash. This is an XML parser, not a forgiving HTML one.

What happens to your data

DOMParser is used here purely as a gatekeeper: the document it builds is discarded immediately and the indenting is done by a hand-written tokeniser walking the raw string, so nothing is ever executed and the parsed tree never reaches the page. Invalid input stops at the browser's own parser-error text with the output box left empty, and neither that message nor your document leaves the tab.

Last updated August 2026

Something has handed you a wall of XML on a single line — a SOAP response out of a log, a feed viewed as source, a config file a build tool rewrote with no line breaks. Nothing shows where one element ends and the next begins.

Before reformatting anything, decide which kind of XML you are holding. Record-shaped XML — configuration, feeds, exports, API envelopes — carries no meaning in the whitespace between tags, so putting each element on its own line changes nothing a parser notices. Document-shaped XML, where text and elements are mixed inside one parent, is the opposite: the spaces around an inline element are part of the sentence. Reading is safe either way; saving the result over the original is only safe for the first kind.

The other thing to settle up front is what formatting cannot do. A document either parses or it does not, and pretty-printing sits downstream — it will not repair a missing closing tag, a bare ampersand, or two root elements pasted together out of a log. Parsing is not correctness either: well-formed means the syntax holds, valid means the document matches a DTD or schema.

The common mistake is treating the output as the same bytes rearranged. It is the same information rearranged — and where a document carries a digital signature, or a hash was taken over it, reformatting breaks both.

How it works

Toolvore works in two passes, both inside your browser. The first is a gate: the text goes to DOMParser in XML mode, and if the browser reports a parser error, that message — usually naming a line and column — appears in red with the output box left empty. The gate runs for Minify as well as Format. The second pass ignores that parsed document; a hand-written tokeniser walks the raw string, splitting it into tags, text, comments and CDATA, then prints each on its own line at a depth that opening tags raise and closing tags lower, indented by the two or four spaces you chose. Attributes survive exactly as typed, because nothing re-serialises them. The weaknesses follow from the same design: text is trimmed and its inner runs of whitespace collapse to single spaces, inside a CDATA block as much as anywhere; Minify is one regular expression removing whitespace between a > and a <, blind to whether that gap sits inside a comment.

Common use cases

A SOAP response pasted out of a server log
An RSS feed or sitemap that arrived as one line
Finding the unclosed tag in a build config
Comparing two API responses in a diff
Collapsing a formatted document for a test fixture
Making a vendor's XML readable enough to quote in a bug report

Frequently asked questions

What is the difference between well-formed and valid XML?＋

Well-formed is grammar: one root element, every tag closed, tags nested rather than overlapping, attribute values quoted, reserved characters escaped. A browser's XML parser checks that and nothing more, which is why a document can be accepted and still be wrong for whoever consumes it. Valid is the next question — whether the document matches a DTD, an XML Schema or a RELAX NG grammar saying which elements may appear, in what order, and what their values look like. Validation needs that schema in hand and a validating parser such as xmllint.

Why does my XML fail to parse because of an ampersand?＋

XML reserves five characters and expects them written as entities in text: an ampersand becomes &, less-than becomes <, greater-than becomes >, and inside an attribute value the character delimiting it needs " or '. A bare ampersand is the commonest cause of a document that looks fine and refuses to parse, and it usually arrives inside a URL, where the ampersands joining query parameters need escaping like any others. A numeric character reference is legal; a half-written entity with no semicolon is not, and a named entity XML has never heard of, such as  , fails unless a DTD declares it.

Is whitespace significant in XML?＋

To the parser, whitespace inside an element's text content is content — preserved and handed to the application, which decides whether to care. Between tags, where only elements are allowed, most consumers treat it as ignorable formatting, and that is why indenting a configuration file is harmless. Mixed content is where the two collide: in a paragraph holding both words and inline elements, the space before an emphasised word is real text, and reindenting by line moves or loses it. The xml:space attribute set to preserve is the document's own way of saying leave this alone.

Is it safe to paste confidential XML into an online formatter?＋

That depends entirely on where the work happens, so it is worth checking rather than assuming. Both steps here run in the page: the check uses the browser's own DOMParser, the indenting is done by code walking the string, and no request carries your document anywhere. XML mode builds a document rather than executing anything, and that document is dropped as soon as the check passes. Where a formatter posts to a server instead, a SOAP envelope holding credentials or personal data has landed in somebody else's logs, and deleting the tab does not take it back.

Why will my HTML not parse as XML?＋

XML has no forgiving mode. HTML lets you write a void element such as a line break with no closing slash, leave an attribute value unquoted, give an attribute no value at all, and close tags in the wrong order; an XML parser refuses all four. Case matters too: an opening tag and its closing tag must match exactly. Named entities are the other trap, since HTML defines hundreds and XML defines five. XHTML exists precisely to be the dialect that satisfies both parsers, which is why an XHTML page survives a strict parse and an ordinary page does not.

How do I format XML from the command line?＋

xmllint, part of libxml2 and already on most Linux and macOS machines, does it with --format, and --noblanks first makes it reindent a document that already carries whitespace. Python needs no install either: pipe the file through xml.dom.minidom and toprettyxml, accepting that it adds blank lines wherever whitespace already existed. PowerShell can load the file into an XmlDocument and write it out through an XmlTextWriter with indentation switched on. All three parse and re-serialise, which normalises your attribute quoting and entity spelling as a side effect — usually welcome, occasionally not in a file under review.

Can an XML file have more than one root element?＋

No. Exactly one element has to contain everything else, and that rule catches people pasting from logs, where each request was written as its own small document and several have been copied together. A file shaped like that is a fragment rather than a document, and parsers reject it with a message about content at the end of the document — which reads like a problem at the bottom when the real cause is the second root. Wrapping the lot in an element you invent costs nothing. Comments may sit outside the root; elements may not.

What is a CDATA section for?＋

A CDATA section marks a run of text the parser reads literally, so ampersands and angle brackets inside it stop counting as markup. It exists where escaping would be unbearable — an embedded fragment of HTML, a snippet of code, a regular expression full of reserved characters. It is neither a comment nor any kind of protection: the content is ordinary text content, and the application receives it as if you had escaped every character by hand. The one thing it cannot contain is the sequence that ends it, so a section carrying that sequence has to be split in two.