XML Formatter

Indent an XML document one element per line, or strip it back to a single line, without sending it anywhere.

Runs on your deviceDeveloperWorkingNo account needed

What this tool does

XML Formatter reads your document with a parser written for this page rather than the browser's own, builds a tree of elements, attributes, comments, CDATA sections and processing instructions, then writes that tree back out. Pretty-print puts one element per line at the indentation you choose; Minify drops the whitespace between elements and joins what is left onto one line, the exception being a comment or CDATA section carrying its own line breaks, which are copied through untouched and keep them. The XML declaration, any processing instructions and a DOCTYPE — internal subset included — are copied through exactly as written, and attributes keep their original order and quoting on the element's own line, however long the list gets.

The check it performs is structural, and it is worth knowing where that stops. It catches a closing tag that does not match the element it closes, a tag or comment or CDATA section that is never terminated, and a stray closing tag with nothing open — each named with the line and column at which the reader gave up. Input holding no element at all is turned away as well, though that one message arrives without a position, there being nothing in the text to point at. It looks no further than shape: no DTD or XSD is consulted, entity references and namespace prefixes pass through unresolved, element names are not tested for legality, and an unquoted attribute value or a second top-level element is accepted rather than refused. It will happily beautify XML that a strict validator would reject.

Rewriting whitespace is the one way the output can differ from the input in substance. Text is normalised — runs of spaces, tabs and newlines collapse to a single space, and the padding around an element's text is trimmed — so a document whose text content is whitespace-sensitive comes back changed, and an xml:space="preserve" attribute is not honoured. Two things are left alone. CDATA sections are reproduced character for character, and mixed content, where text sits beside child elements, stays on one line instead of being broken up, because indenting it would push spaces into the prose itself.

Everything runs in this browser tab, so the document is not uploaded and the page keeps working with the network switched off. Input arrives by pasting; there is no file picker on this tool, and the parse tree is built in memory, so the practical ceiling is whatever your browser will hold rather than a number set here. The hint beside Copy output opens with the words Valid XML, then reports how many elements were found and how deep the nesting goes, plus the size before and after when you have minified. Take that opening as shorthand for a shape that held together rather than a verdict on the document: it is printed for anything the reader reached the end of, the two-root and illegal-name cases above included.

How to use it

  1. Paste the XML. Type or paste the document into the input box — there is no file picker here — or press Load sample for a short catalogue with attributes, two repeated elements and a comment between them.
  2. Pick pretty-print or minify. Pretty-print indents one element per line, and the indentation choice — 2 spaces, 4 spaces or a tab — is shown only in that mode. Minify strips the line breaks and indentation back out again.
  3. Decide about comments and empty elements. Remove comments strips them from the output. Collapse empty elements rewrites <tag></tag> as <tag/>, and also closes an element that held nothing but whitespace.
  4. Run it and read the hint. Sound structure gives you the rewritten document, an element count and the maximum nesting depth. A fault instead empties the output box and raises the reason in a notification that fades after a few seconds, so read it before it goes.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Making a one-line export readable

Feeds, SOAP envelopes and build artefacts often arrive with no line breaks at all. One pass gives you pretty XML you can scan for the element you actually came for.

Diffing two versions of a config

Reformat both files with the same indentation first and the diff stops reporting whitespace, leaving only the elements and attributes that genuinely moved.

Finding the tag that broke a build

A mismatched or unclosed element is named with a line and column, which is quicker to act on than the position a parser deep in your pipeline reports.

Shrinking a document before it travels

Minify removes the indentation a generator added and shows the byte count either side of the change, which is worth doing to XML you embed or transmit repeatedly.

Questions

Is my XML uploaded?
No. The document is read and rewritten inside this browser tab, so no copy reaches a server and none is kept here. Close the tab and the text goes with it.
Does it validate my XML?
Only the structure. It will tell you that <title> was closed with </titel> on line 12, or that the root element never closed. It will not tell you that a required element is missing, that an entity was never declared, or that the document breaks a schema, because no DTD or XSD is read. Treat it as an XML lint for shape, not for conformance.
Why did the spacing inside my text change?
Text nodes are normalised, so repeated whitespace becomes one space and the padding around an element's text is dropped. Where a value depends on its own line breaks or indentation, wrap it in a CDATA section — those are reproduced exactly — or leave that document unformatted.
Why is <tag></tag> not written as <tag/>?
Because collapsing empty elements is a choice, and it is off by default. Switch it on and both an empty pair and an element holding only whitespace become <tag/>. Some consumers treat the two spellings differently, which is why it is not done unasked.
Can I format HTML with it?
Rarely. HTML permits tags that are never closed, such as <br>, <img> and <li>, and this reader treats an unclosed tag as a fault, so an ordinary web page is refused. XHTML and SVG are XML and format normally, though SVG Optimizer is the better choice when the goal is a smaller file rather than a readable one.
Should I use this or XML to JSON?
Use this when the document has to stay XML and only needs to be legible or smaller. Use XML to JSON when something downstream wants JSON — and note that the conversion drops comments and the declaration, which formatting keeps.

Related tools