XML Formatter & Validator

Pretty-print or minify XML with an indent you choose, and get a real line and column for any syntax error. Nothing is uploaded and no library is needed.

🌐 Español

🔒 Private by design: your text is processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

Two problems, one page

XML arrives in two states that need opposite treatment, and this page handles both.

Machine generated XML comes as a single unbroken line, because whitespace between elements costs bytes and no program cares. It is unreadable, and the only way to understand its structure is to reformat it.

XML you are about to send has the opposite problem. Your carefully indented file carries whitespace that means nothing to the receiver and adds to every request, and stripping it is the last step before shipping.

The mode selector picks a direction, and both operations understand the document’s structure rather than manipulating text, which is why neither breaks anything.

Formatting or minifying

  1. Paste your XML into the box.
  2. Choose Format, pretty-print or Minify.
  3. Set an Indent size in spaces, format mode only between 1 and 8.
  4. Run it, then copy or download the result.

Well formed is not the same as valid

The distinction is worth being precise about, because tools blur it constantly.

A well formed document is syntactically correct XML. Every opening tag has a matching close, elements nest properly rather than overlapping, attribute values are quoted, and reserved characters are escaped. That is what is checked here.

A valid document additionally conforms to a schema that says which elements may appear where, what types their contents are, and what is required. That check needs the schema, which this tool has not been given.

In practice well formedness catches most of what goes wrong with hand edited XML, because the failures are missing closing tags, unquoted attributes and stray characters. A document that passes here and is still rejected by its consumer is a schema problem, not a syntax one.

Errors come with a location

A parse failure is only useful if it tells you where. The result box therefore reports a line and column alongside the parser’s own reason.

Getting that location out is less straightforward than it sounds, because browsers report parse errors as a document rather than as an exception, and each browser family words it differently. Both common phrasings are recognised, and a browser producing something unfamiliar has its raw text passed through unchanged rather than having a plausible looking line number fabricated for it.

Browsers also append a sentence about rendering the page up to the first error, which is a relic of the parser existing to display documents. It is stripped, since it says nothing about your XML.

What formatting deliberately leaves alone

Comments, CDATA sections, processing instructions and the document type declaration are preserved exactly and placed on their own lines. Their contents are structurally meaningful and re-indenting inside them could change what they mean, so the formatter decides only which line they occupy.

Text content inside an element is likewise untouched, since it is data. An element whose only meaningful content is text keeps that text on the same line, which is what makes a formatted data document readable rather than tripling in height.

The honest limitation is genuinely mixed content, where text and child elements interleave inside one parent as they do in a paragraph of markup. That shape has no whitespace preserving pretty print, and it takes the multi line layout with the incidental whitespace changes that implies. Configuration files, API payloads and feeds essentially never use it.

For the other structured formats that arrive equally mangled, JSON Formatter and SQL Formatter do the same job, and Minify CSS covers stylesheets. To convert between formats rather than reformat one, XML to JSON goes both ways and YAML to JSON covers configuration files.

Formatting both versions of a document before running Diff Text is the standard trick for comparing two XML files, since it removes whitespace as a source of spurious differences. The rest are on the dev tools hub.

See it in action

Screenshot of the XML Formatter & Validator tool with the sample input “<tools><tool slug="png-to-jpg" category="image" …”, Mode set to Format, pretty-print, Indent size in spaces, format mode only set to 2
XML Formatter & Validator mid-process: the sample input “<tools><tool slug="png-to-jpg" category="image" …”, Mode set to Format, pretty-print, Indent size in spaces, format mode only set to 2.
Screenshot of the XML Formatter & Validator result screen showing the generated output “<tools> <tool slug="png-to-jpg" category="image"…”
The finished result: the generated output “<tools> <tool slug="png-to-jpg" category="image"…”. The download link is a local blob URL — the file never leaves your device.

Frequently asked questions

Does it actually validate the XML?

It checks that the document is well formed, which is the check that matters for most problems. Tags must be balanced and properly nested, attributes must be quoted, and the syntax must parse. What it does not do is validate against a schema, so it will not tell you that an element is in the wrong place according to a specification, only that the document itself is structurally sound.

What happens when the XML is broken?

The result box shows the failure with a line and column number and the parser's own reason for stopping. The location is extracted from the browser's own parser output, which differs in wording between browsers, so the extraction handles more than one phrasing. If a browser produces something unrecognised, the raw text is passed through as it is rather than a line and column being invented.

Why does the parser report a rendering message alongside the error?

Because browsers append a note about rendering the page up to the first error, which is a leftover from the parser being designed for displaying documents rather than reporting on them. That trailing sentence is stripped out, leaving the part that names the actual problem, since a line about page rendering in a formatter's output is noise.

What does minify mode remove?

The whitespace between elements that exists only for readability. It does not touch text content inside an element, since that is data, and it does not remove comments or processing instructions. The result is one long line, which is what you want for a payload being sent over a network rather than read by a person.

How does formatting handle a comment or a CDATA section?

Both are kept verbatim on their own line and are never split or reflowed. The same applies to processing instructions and a document type declaration. Those constructs have meaning that whitespace changes could break, so the formatter leaves their contents exactly as they were and only decides which line they sit on.

What about an element containing both text and child elements?

That is the one shape where a formatter has to make a compromise. An element whose only meaningful child is text keeps that text on the same line, which is the readable outcome for the vast majority of data documents. Genuinely mixed content, meaning text interleaved between child elements as in a paragraph of markup, falls into the multi line layout and its incidental whitespace changes as a result.

Does my XML go anywhere?

No. Parsing and formatting both happen inside your browser tab, so the document never leaves your device. That matters because XML in the wild is usually a configuration file, an API payload or an export, all of which routinely contain credentials, internal hostnames or customer data.

Related tools