Skip to content
ToolBoxGeniehome

XML Formatter

Developer Tools · Added

Indent an XML document so its structure is visible, or collapse it to one line for transport — and find out whether it is well-formed while you are there, with the line number of anything that is not. Elements whose content is text mixed with markup are reproduced byte for byte, because in those the spaces are part of the content rather than layout.

Mode

Parsed in your browser. Nothing you paste is uploaded, and no external entity is fetched.

How to use the xml formatter

  1. 1Paste your XML, or press Load a sample document to see how it is treated.
  2. 2Choose Beautify to indent it or Minify to strip the whitespace between elements.
  3. 3Set the indentation, and decide whether to tidy the spacing between attributes and keep comments.
  4. 4Read the well-formedness panel: every unmatched or unclosed tag is listed with its line number.
  5. 5Copy the result or download it as a .xml file.

Examples

A nested record

Input
<book><title>Deep Work</title><price>499</price></book>
Result
<book>\n <title>Deep Work</title>\n <price>499</price>\n</book>

Elements holding only text stay on one line; only the element-holding ones are broken apart.

Mixed content is left alone

Input
<p>Hello <b>there</b> world</p>
Result
<p>Hello <b>there</b> world</p>

Indenting this would insert spaces into the sentence. The formatter detects text alongside markup and reproduces the whole element unchanged.

A mismatched tag

Input
<a><b></a>
Result
Line 1: closing tag </a> does not match <b>

The error names both tags and the line each was opened on, which is more useful than a character offset.

About the xml formatter

The whitespace problem, and how this tool decides

Every XML formatter faces the same question and most answer it badly. Whitespace between two elements almost never means anything — the newline between one record and the next is layout. Whitespace inside a run of text absolutely does. XML itself refuses to take a position, delegating it to xml:space and to the schema, neither of which a standalone formatter has.

The rule used here is to classify each element by what is inside it. If its children are all elements, the whitespace between them is layout and can be replaced with indentation. If it contains text and nothing else, the element stays on one line with its text trimmed. If it contains both text and elements, the whole subtree is reproduced exactly as it was given, character for character.

That third case is where careless formatters do real damage. Indenting the contents of a paragraph that contains an emphasis tag inserts a newline and two spaces into the middle of a sentence, and when that document is rendered the extra space shows. Detecting the case and refusing to touch it costs nothing and prevents a class of silent corruption.

Reading XML you did not write

Most XML people deal with today arrives from somewhere else — a SOAP response, an RSS feed, a configuration file, an Office document unzipped, an export from a system nobody has the source for. It is usually minified or wrapped at an arbitrary column, and the first job is always to see its shape. The element count and nesting depth reported here are a quick sanity check on that: a depth of twelve on a document you expected to be flat says something before you have read a line.

CDATA sections deserve particular care and get it. Everything between the opening and closing markers is character data by definition, including angle brackets and ampersands that would otherwise be markup, which is exactly why the section exists. A formatter that treats a CDATA body as content to be re-escaped or re-indented destroys embedded scripts, SQL and HTML alike, so the parser here consumes the whole section as one unit and never looks inside.

The other thing worth knowing when reading unfamiliar XML is that attribute order is not significant and never has been. Two documents differing only in attribute order are equivalent to a parser. If a diff is showing attribute reordering as a change, that is a formatting artefact rather than a content change, and normalising both files through the same formatter first is the way to see what really moved.

Frequently asked questions

What does well-formed actually check?
Structure only: that every element that opens also closes, that they nest without crossing over, that closing tags match their openers, and that the document has exactly one root element. That is the XML specification minimum, and it is what a parser refuses to read past. It says nothing about whether the elements are the right ones or appear in the right order.
So is this a validator?
Not in the strict sense of the word. Validation means checking a document against a schema — a DTD, an XSD or a RELAX NG grammar — which decides which elements may appear where, how many times, and what may go inside them. That needs the schema, and this tool never fetches anything. What it gives you is the well-formedness check, which is the layer underneath validation and the one that catches most hand-editing mistakes.
Why was my spacing inside an element left as it was?
Because that element has mixed content — text and child elements together — and there the whitespace is meaningful. XML, unlike HTML, does not define whitespace between elements as insignificant; that is a convention that holds for data-shaped documents and fails for document-shaped ones. Rather than guess, the formatter indents elements whose children are all elements and reproduces anything with text alongside markup exactly as supplied.
Are external entities or DOCTYPE references fetched?
No. The DOCTYPE line is treated as text and passed through, and nothing referenced from it is retrieved. This matters beyond convenience: fetching external entities is the mechanism behind the XXE class of vulnerabilities, where a crafted document persuades a parser to read local files or make network requests. Nothing here resolves an entity, and nothing leaves your browser.

Related tools