XML Formatter & Validator

Introduction to XML formatting and well-formedness

This XML formatter makes dense markup easier to read, produces a compact minified copy, and checks whether a document is well-formed. It also reports the first parser error and summarizes elements, attributes, namespaces, text nodes, comments, CDATA sections, processing instructions, and nesting depth. Processing happens in the current browser tab, so pasted XML is not uploaded by this page.

Well-formedness is a syntax standard, not a guarantee that the data is correct. A well-formed XML document has one root element, matching case-sensitive tag names, orderly nesting, quoted and unique attributes, legal characters, escaped reserved characters, and valid namespace-prefix bindings. This checker does not apply an XSD, DTD, Relax NG schema, or Schematron rules, so it cannot decide whether an order number, date, element sequence, or required field satisfies an application’s contract.

The tool parses the source into a document tree before serializing it. That is more dependable than manipulating nested markup with regular expressions and allows conservative whitespace handling. Mixed content such as <p>Read <em>this</em> now.</p> may depend on spaces around inline elements, while xml:space="preserve" explicitly protects whitespace in a subtree. The formatter therefore reflows structural content only when it can do so without intentionally changing character data.

How to use the XML formatter, validator, and minifier

Paste a complete XML document into the XML document field, or load the sample. The input must have one enclosing root element; unrelated sibling fragments need a temporary wrapper. For formatted output, choose an indentation unit of two spaces, four spaces, or one tab. This setting changes presentation rather than XML meaning. Two spaces keep deeply nested files compact, four spaces make moderate nesting more visible, and tabs let an editor determine the displayed width.

• Format XML checks the source and writes an indented copy.
• Validate only checks syntax without rewriting the document.
• Minify removes recognized layout whitespace between structural nodes while preserving significant text.
• Copy result copies transformed XML or an error report, while Download creates formatted.xml locally.

Press Ctrl+Enter or Command+Enter while editing to format the source. If parsing fails, the result includes the browser’s message and, when available, a line, column, source line, and caret. The reported position is where the parser could no longer continue; an omitted quote or closing tag may appear earlier. Correct the first problem, validate again, and repeat because parsers commonly stop at the first fatal XML error.

For important configuration, API, feed, or build files, compare transformed output with the source and test it in the consuming application. Expected differences include indentation, line endings, escaping, and equivalent empty-element notation such as <item/>. A successful result confirms parseable XML syntax, not application compatibility.

The XML grammar and indentation formulas

The XML 1.0 document production expresses the single-root requirement. A document contains a prolog, one document element, and optional trailing miscellaneous content such as comments, processing instructions, or whitespace:

Because there is one element term, two sibling roots are invalid. Every non-empty start tag must also have an end tag with the same qualified name:

Matching is case-sensitive: <Item> cannot be closed by </item>. Nesting is stack-like, so <a><b></a></b> is invalid because b must close before its parent a.

For formatting, the root element starts at depth zero and each child element is one level deeper than its parent:

If the selected indentation unit has k characters, the prefix for a node on its own line has this character length:

With one line-feed character per eligible node, the output length can be described using P, the nodes placed on separate lines, and L, the serialized content before those prefixes:

Only structural children are candidates for separate lines. The following predicate summarizes the important exclusion: an element is not breakable when it has CDATA or significant text. The implementation also requires a structural child and treats whitespace as removable layout only when it contains a line break.

This conservative assumption protects spaces between inline elements and honors inherited xml:space="preserve". It may retain more whitespace than a schema-aware formatter would, but avoiding an unintended text change is safer than pursuing the smallest output.

Serialization escapes ampersands and less-than signs in character data. A greater-than sign is escaped when needed to avoid creating the CDATA closing sequence:

Attribute values additionally escape their delimiting quotation mark. Tabs, carriage returns, and line feeds are written as character references so another parse does not normalize them into spaces. XML predefines only &, <, >, ", and '; an HTML entity such as   needs a DTD declaration and otherwise causes an error.

The serializer visits each parsed node once. For an element with k child subtrees, its work is:

The constant term covers the current node and attributes. Overall work is linear in the node count plus generated output length, although extreme depth increases indentation and recursive call depth. The input limit is four million characters to reduce the chance of an unresponsive tab.

Namespaces and qualified XML names

Namespaces distinguish names from different XML vocabularies. A default declaration such as xmlns="urn:example:orders" applies to unprefixed element names, while xmlns:meta="urn:example:metadata" binds meta for names such as meta:source. Default namespaces do not automatically apply to unprefixed attributes, so an ordinary id attribute usually has no namespace.

Every used prefix must have an in-scope declaration, except the reserved XML prefix with its predefined binding. Descendants may rebind prefixes, so the metrics table records each distinct declaration and the element where it appears. Formatting preserves qualified names and declarations rather than renaming prefixes or trying to redesign the namespace map.

Worked example: correcting a mismatched XML product tag

Consider <catalog><product><name>Mug</name><product></catalog>. The second product tag was intended to be </product>. When the parser reaches </catalog>, the innermost open element is still product, so the reported location may be the catalogue end tag even though the typo appears earlier.

After correcting the tag, two-space formatting places product one level under catalog and name two levels down. The text-only name remains on one line because line breaks around Mug would become character data. Adding id="1" id="2" would make the source invalid again because attributes on one element must have unique names.

If the product name is written as Mugs & Cups in XML source, the bare ampersand incorrectly begins an entity reference. Source markup must use Mugs & Cups. Similarly, <meta:rating> requires an in-scope xmlns:meta declaration. Fixing either syntax error does not prove that the resulting value or namespace is the one expected by the catalogue application.

Common XML syntax errors to check first

Attributes need quoted values, so <item status=open> is invalid and <item status="open"> is valid. Comments cannot contain -- within their content. CDATA ends at the first ]]>, so that sequence cannot appear directly inside a CDATA section. An XML declaration, when present, must appear at the beginning apart from a possible byte-order mark.

Copying HTML into XML also causes frequent failures. XML does not inherit HTML’s tolerant parsing, case handling, optional closing conventions, or large set of named entities. Every XML element must close or use self-closing syntax, names remain case-sensitive, and only the five predefined XML entities are available without a DTD.

Validate after each correction rather than trying to infer all problems from one message. An unclosed tag or quote can make later markup appear to be the error, and resolving the first contradiction often reveals another independent issue.

Interpreting XML metrics and limitations of the result

A successful format or minify run means the browser produced a parsed XML document. The metrics show the root name, element and application-attribute counts, significant text nodes, CDATA sections, comments, processing instructions, maximum element depth, declarations, namespaces, and character-count change. A high depth is not automatically invalid, but an unexpected count or namespace can reveal truncation or a structural change worth investigating.

The character difference measures presentation, not semantic quality or network compression. Formatted XML usually grows as indentation is added; minified XML may shrink when removable layout whitespace is present. Mixed content and preservation rules can produce little change. HTTP gzip or Brotli generally saves more transfer size than aggressive XML rewriting.

Formatting is not Canonical XML. Do not treat this output as the canonicalization required by a digital-signature protocol, because equivalent textual changes can invalidate a signature. The browser also does not expose a document type’s complete internal subset. Validate-only mode is the prudent choice for signed or DTD-dependent documents unless a dedicated XML library handles the required canonicalization and declarations.

The textarea already contains decoded Unicode, so an encoding declaration cannot reinterpret original file bytes. If text is already corrupted by the wrong file encoding, repair it in a tool that can reopen the source bytes. External entities are not fetched, and the checker does not assess hostile URLs, misleading content, oversized values, or authorization. Apply schema validation, domain checks, security review, and destination-specific tests before production use.

Using the XML checker in development workflows

For a failing API response, validate syntax before debugging object mapping, then inspect the formatted hierarchy and namespaces. For configuration files, compare the root, depth, and counts with a known-good version. In code review, use a stable team formatting policy so cosmetic rewrites do not hide meaningful changes.

Preserve the original source when tests depend on exact quotation styles, entity references, CDATA boundaries, comments, or whitespace. Parsing and serialization can replace those spellings with XML-equivalent forms. For very large or deeply nested production feeds, prefer a streaming parser or command-line XML tool over a browser textarea.

Sources. Syntax, escaping, attribute normalization, CDATA, xml:space, and entity rules come from the W3C XML 1.0 Recommendation. Namespace rules come from Namespaces in XML 1.0. See XML 1.0, Namespaces in XML, and the DOM parsing specification.

Common questions about this XML checker