XML Formatter & Validator

Q: Why does my XML fail on an ampersand?

Because a bare & starts an entity reference, so the parser reads the following characters expecting something like amp; or lt; and fails when it does not find one. This is the single most common XML error, and it usually arrives via a URL in an attribute — a query string joining parameters with & is invalid XML unless it is written as &. The other four characters needing the same treatment are less than, greater than, apostrophe and double quote, though the last three are only strictly required in specific positions.

Q: Is XML case-sensitive?

Yes, entirely, and this catches people arriving from HTML where it does not matter. An element opened as must close as , not , and the two are different element names as far as any consumer is concerned. Attribute names are equally case-sensitive. Well-formedness errors from mismatched case tend to be reported at the closing tag, which can be a long way from the opening one in a large document, so the line number in the error is often not where the real mistake is.

Q: What does well-formed mean, and is it the same as valid?

They are different, and the distinction matters. Well-formed means the syntax is correct: tags are balanced and properly nested, there is exactly one root element, entities are escaped, and attribute values are quoted. Valid means the document also conforms to a schema — an XSD or DTD that says which elements may appear, where, and how often. This tool checks well-formedness, which is the necessary first step. A document can be perfectly well-formed and still be rejected by a system expecting a particular schema.

Q: Is whitespace in XML significant?

It can be, which is why reformatting is not always harmless. Whitespace inside an element that holds text content is part of that content, so adding indentation inside Jane changes the value. Whitespace between elements is generally ignorable. This tool re-indents structural whitespace while leaving text content alone, but if your consumer treats mixed content strictly, format with care and check the result rather than assuming the reformatted document is equivalent.

Q: What happens to comments and CDATA?

Formatting parses the document into a structure and writes it back out, so comments are not carried through — the same limitation every structural reformatter has. CDATA sections are detected and reported, since their contents are deliberately exempt from parsing and are usually there to hold something that would otherwise need escaping. If your document depends on either, treat this as a validator and an inspector rather than something to paste the output of back over your source.

Q: Are namespaces handled?

Prefixed names are preserved as written, and their presence is reported, but they are not resolved to their declared URIs. That means the tool treats soap:Envelope as an element whose name happens to contain a colon, which is enough for formatting and well-formedness but not a full namespace-aware processing model. For documents where prefix resolution actually matters — SOAP payloads and most enterprise schemas — use this for readability and a proper namespace-aware parser for correctness.

Check XML is well formed, get the failing line when it is not, and see it re-indented with consistent structure.

XML

Indent width

Formatted

Parsing and formatting run entirely in your browser. Comments are not preserved in the formatted output, since formatting works by parsing and re-emitting the document.

What It Does

Paste XML and this tells you whether it is well formed, points at the line if it is not, and shows it re-indented so the structure is actually readable. Well-formedness is a narrow but essential bar: balanced and properly nested tags, exactly one root element, quoted attribute values, and the five special characters escaped. Most XML that fails in production fails one of those, and the commonest culprit by a wide margin is a bare ampersand from a URL that was pasted into an attribute without escaping. Alongside the verdict the tool reports what the document actually contains — how many elements, how deep it nests, whether namespaces or CDATA are in play — because that is usually the context you need before deciding what to do about an error.

When to Use It

An API returned XML on one enormous line and you need to see its structure before you can work out what it contains.
A feed or configuration file is being rejected as malformed and you need the line number rather than a generic parse failure.
You are debugging a SOAP payload and want the nesting laid out clearly to find the element you actually care about.
A document was assembled by string concatenation and you suspect an unescaped character from a URL has broken it.
You want to check the depth and element count of a document before writing code that walks it.

Worked Examples

<catalog><book id="1"><title>XML Basics</title><author>Jane Doe</author></book></catalog>

Valid but unreadable on one line, which is how XML usually arrives from an API. Formatting reveals the nesting and the tool reports the element count and depth.

<link href="https://example.com/page?a=1&b=2"/>

The classic failure. The bare ampersand joining the query parameters starts an entity reference that never terminates, so the document is not well formed — it needs to be written as &.

<root><Item>one</item></root>

A case mismatch. XML is entirely case-sensitive, so <Item> and </item> are different names and the document is malformed even though it looks fine at a glance.

Features

Well-formedness checking with the failing line reported

Consistent re-indentation at your chosen width

Unescaped ampersand and entity errors identified

Element

attribute and text node counts

Maximum nesting depth reported

Namespace prefixes detected

CDATA sections detected and flagged

Handles documents arriving on a single line

One-click copy of the formatted result

Runs entirely in your browser

How to Use

1. Paste your XML into the input box. 2. The verdict appears immediately, with the line number if it is malformed. 3. The formatted version appears below with consistent indentation. 4. Adjust the indent width to match your project's style. 5. Copy the result, noting that comments are not carried through.

Common Mistakes

Leaving an ampersand unescaped. A URL in an attribute is the usual source, and a bare & is invalid XML no matter how obviously it was meant literally.
Assuming tag names are case-insensitive. They are not, and a mismatch is often reported at the closing tag far from where the real mistake is.
Building XML by concatenating strings. Any value containing a special character breaks the document, which is exactly why every language ships an XML writer.
Confusing well-formed with valid. Passing here means the syntax is correct; it says nothing about whether the document matches the schema a consumer expects.
Pasting formatted output back over a source file with comments. Structural reformatting parses and re-emits, so comments do not survive.

Frequently Asked Questions

Why does my XML fail on an ampersand?

Is XML case-sensitive?

What does well-formed mean, and is it the same as valid?

Is whitespace in XML significant?

What happens to comments and CDATA?

Are namespaces handled?