XML Formatter and Validator with Error Lines

Format, prettify and validate XML in one step

Paste XML and press Format. The page first hands the text to your browser's built-in XML parser (DOMParser with the application/xml type), the same strict parser browsers use for SVG and XHTML. If the document is not well-formed, nothing is reformatted: you get the parser's message, and the line and column where it stopped when the browser reports one. Only well-formed input is pretty-printed, so the XML beautify step can never hide a broken document behind neat indentation.

The formatter then re-indents the document with 2 spaces, 4 spaces or tabs. Each element starts on its own line, and an element that contains only text stays on one line, so <title>XML Developer's Guide</title> is not exploded into three lines. Comments, CDATA sections, processing instructions such as <?xml-stylesheet ?> and the DOCTYPE declaration, including any internal subset, are copied exactly as written; nothing inside a CDATA block is touched, so embedded HTML or script survives. Attribute order and quoting are left alone too.

Everything runs in your browser. The XML you paste is not uploaded, which matters for SOAP payloads, SAML assertions, Maven or .NET config files and product feeds that often contain credentials, account IDs or customer data.

What the XML validator checks, and what it does not

The Validate button checks well-formedness: exactly one root element, every start tag closed or self-closed, correct nesting, quoted attribute values, no duplicate attributes on an element, legal names and properly escaped & and < characters. These are the errors behind most "XML parsing error" messages in feeds, Android layouts and sitemap submissions.

It does not validate against a schema. Checking that a document obeys an XSD, DTD or RELAX NG grammar, for example that <price> must be a decimal, needs the schema file and a validating parser such as xmllint --schema schema.xsd file.xml. Browsers do not perform schema validation, so this page cannot, and it does not pretend to. External entities and DTDs are not fetched either.

Error wording comes from the browser. Chrome and Edge report something like "error on line 3 at column 15: Opening and ending tag mismatch", Firefox says "XML Parsing Error: mismatched tag" with a line number, and Safari is similar to Chrome. Look at the reported position and the line just above it: an unclosed tag usually triggers the error where the parser finally notices, not where the tag was opened.

Indentation, whitespace and minifying

XML treats whitespace between elements as text, so any formatter changes it. This one treats whitespace-only text between tags as insignificant, which is right for configuration, data and feed files. For mixed content, where text and child elements sit side by side, text runs are trimmed and placed on their own lines. Elements marked xml:space="preserve" are emitted exactly as written. Minify does the reverse: it removes whitespace-only text between tags, keeps comments unless you tick Strip comments, and leaves CDATA alone, which shrinks the payload before you embed it in a request or a test fixture.

Output lines are joined with Unix line feeds. Formatting already-formatted XML produces the same result, so it is safe to run on files that are partly indented, and minifying then formatting again returns the same layout.