XML Formatter & Validator

About this tool

XML from an API response, a config export or a SOAP log usually arrives as one long line, or with indentation that has drifted over years of hand edits. This XML formatter parses the document with your browser's built-in XML parser, reports the first error if the document is broken, and then rebuilds it with clean, consistent indentation. You can also minify it back to a single line or just check that it is well-formed. Nothing is uploaded; the XML stays on your device.

How to use the XML Formatter

1. Paste your XML into the input box. A sample product feed is loaded so you can see the result first.
2. Choose an indent: 2 spaces, 4 spaces or a tab. Tick Remove comments if you want comments dropped.
3. Click Format XML to pretty print, Minify to strip the layout whitespace, or Validate only to check the document without changing the output.
4. Read the status line. It shows the number of elements, attributes and nesting depth, or the line and column of the first error.
5. Copy or download the result as formatted.xml or minified.xml.

How the formatter works

The input is parsed with the browser's DOMParser as application/xml. If the parser rejects it, the tool shows the parser's own message with its line and column, plus the offending line with a caret under the column. If it parses, the tool walks the document tree and writes every node back out itself:

• The XML declaration (<?xml version="1.0" encoding="UTF-8"?>) is not part of the document tree, so it is copied from the start of your text exactly as written. The DOCTYPE is copied the same way, including any internal subset in square brackets.
• Comments, processing instructions and CDATA sections are kept. CDATA content is written verbatim, so markup inside it is untouched.
• Namespaces and attributes keep their prefixes and their original order. Every attribute value is written in double quotes, so id='p101' becomes id="p101".
• Escaping: in text, &, < and > are written as entities. In attribute values the double quote is also escaped, and tab, line feed and carriage return become 	, 
 and 
, because a parser would otherwise turn them into plain spaces (attribute-value normalization, section 3.3.3 of the spec).
• Layout: an element that contains only child elements gets one child per line. An element that holds only short text (up to 80 characters, one line) stays on one line, such as <name>Trail Running Shoes</name>. An empty element is written as a self-closing tag like <inv:stock warehouse="west"/>, which means the same thing in XML as an open and close tag with nothing between.
• Mixed content (text and elements side by side, as in Ships in <em>2</em> days) is written on one line exactly as it was, because adding line breaks there would change the text.

Pretty printing does change whitespace that sits only between elements, and it trims leading and trailing whitespace inside short text-only elements. Almost every XML consumer treats that whitespace as layout. If yours does not, mark the element with xml:space="preserve"; the formatter then leaves that element and everything inside it exactly as written. Minify mode removes only whitespace-only text between elements and never trims text.

Well-formed is not the same as valid

The W3C XML 1.0 specification (Fifth Edition) separates two levels. A document is well-formed when it follows the basic syntax rules: exactly one root element, every start tag closed by a matching end tag, properly nested elements, quoted attribute values, no attribute repeated in the same tag, and no literal < or & in text. A document is valid only if it also has a document type declaration and follows the rules that declaration sets out. In practice validity is often checked against an XML Schema (XSD) instead.

This tool checks well-formedness only. It does not load DTDs, XSD schemas or other external files, and it does not check that elements appear in the order a schema requires. "Validate only" here means "check that this parses as XML".

The five predefined entities

XML defines exactly five named entities that every parser understands without a DTD:

HTML names such as   or © are not defined in XML. Use a numeric reference such as   instead, or the parser stops with an error like "Entity 'nbsp' not defined".

Worked example

The sample in the tool is a small product feed: an XML declaration, an xml-stylesheet processing instruction, a comment, and a catalog root that declares the inv namespace prefix. Everything after the comment is on one line, and one attribute uses single quotes. With a 2-space indent, Format XML produces:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="catalog.xsl"?>
<!-- Sample product feed -->
<catalog xmlns:inv="https://example.com/ns/inventory" updated="2026-10-01">
  <product id="p100" status="active">
    <name>Trail Running Shoes</name>
    <price currency="USD">89.99</price>
    <inv:stock warehouse="east">42</inv:stock>
    <description><![CDATA[Lightweight & breathable <b>mesh</b> upper.]]></description>
    <tags>
      <tag>outdoor</tag>
      <tag>footwear</tag>
    </tags>
  </product>
  <product id="p101" status="draft">
    <name>Tom &amp; Jerry Socks</name>
    <price currency="USD">12.50</price>
    <inv:stock warehouse="west"/>
    <note>Ships in <em>2</em> days</note>
  </product>
</catalog>

The status line reports 15 elements, 10 attributes (one of them the namespace declaration) and a depth of 4. The CDATA section is unchanged, so its & and <b> stay literal. Tom & Jerry Socks keeps its entity. The empty inv:stock element became self-closing, and the mixed-content note stayed on one line.

Common XML errors and what they mean

• Unclosed tag. <a><b></a> gives "Opening and ending tag mismatch: b line 1 and a" in Chrome. The reported line is where the parser noticed, which may be after the tag you forgot to close.
• Mismatched case. XML names are case-sensitive, so <Note> cannot be closed with </note>.
• Unescaped ampersand. <co>Tom & Jerry</co> fails; write &. This is the most common error in hand-built XML and in URLs with query strings.
• More than one root. Two top-level elements give "Extra content at the end of the document". Wrap them in one parent element.
• Anything before the declaration. The XML declaration must be the very first thing in the file. Even one space or blank line before <?xml is an error.

Common use cases

• Reading a minified API, SOAP or RSS response while debugging
• Cleaning up Android layouts, Maven pom.xml files or sitemap files before a code review
• Finding the line that breaks an import, then minifying the fixed file for transport

Working with other formats? The JSON Formatter does the same job for JSON, the HTML Formatter tidies web pages, and the YAML to JSON Converter handles config files.