XML Formatter & Validator
Pretty-print or minify XML and find out exactly where a malformed document breaks, reported by line and column.
Well-formed and valid are different things
These two words get used interchangeably and they are not the same test. Well-formed means the document obeys the syntax of XML: one root element, tags properly nested and closed, attributes quoted, characters escaped. A parser can check that on its own.
Valid means the document additionally conforms to a schema — a DTD, an XSD, or a Relax NG grammar — that says which elements are allowed, in what order, with what attributes. Validation requires that schema; XML itself does not carry one by default.
This tool checks well-formedness only, using your browser's parser. It will tell you that
<price>abc</price> is perfectly good XML, because it is —
nothing in XML says a price has to be a number. That constraint lives in your schema.
What the browser parser will reject
| Problem | Example | Why it fails |
|---|---|---|
| Unclosed tag | <a><b></a> | Tags must nest, never overlap |
| Two roots | <a/><b/> | Exactly one root element is allowed |
Unescaped & | <t>A & B</t> | & always starts an entity |
| Unquoted attribute | <a id=1> | Attribute values must be quoted |
| Undeclared prefix | <dc:title> with no xmlns:dc | A namespace prefix must be bound |
| Lowercase mismatch | <Tag></tag> | XML is case-sensitive; HTML is not |
The last one is the most common mistake when someone writes XML by hand after years of writing HTML. Browsers silently accept mismatched case in HTML; an XML parser is required to reject it.
Five characters that must be escaped
Inside element content you must escape & and <. Inside an
attribute value you must also escape the quote character you used as the delimiter. The
other three are conventional rather than required, but escaping them avoids surprises:
| Character | Escape as | Required? |
|---|---|---|
& | & | Always |
< | < | Always |
> | > | Recommended (required after ]]>) |
" | " | In double-quoted attributes |
' | ' | In single-quoted attributes |
Order matters when escaping: replace & first, or you will double-escape
the ampersands you just introduced and end up with &lt;.
CDATA is not an escaping shortcut
<![CDATA[ ... ]]> tells the parser to treat everything inside as
literal text, so < and & need no escaping. It is
genuinely useful when you are embedding code or markup as text.
Two caveats: the sequence ]]> terminates the section, so content
containing it has to be split across two CDATA blocks; and a CDATA section is not
recognised inside an attribute value. It also hides the content from anything doing
schema validation or XPath on the text, which is why overuse causes problems later.
Namespaces are URIs, not addresses.
xmlns="http://example.org/ns" looks like a location, but nothing is
fetched from it. It is an opaque identifier, and two documents are in the same
namespace only if those strings are byte-identical — including trailing slash
and case.
Frequently asked questions
Why does my valid-looking XML fail to parse?
Most often an unescaped ampersand in a URL, or a stray character before the declaration — even a space or a byte order mark ahead of <?xml will break it.
Should I use attributes or child elements?
Attributes suit metadata about the element — an id, a currency, a language code. Child elements suit data that may itself grow structure, repeat, or need to hold mixed content. Attributes cannot repeat and cannot contain markup, so anything that might become complex belongs in an element.
Is XML still worth using over JSON?
For new APIs, JSON usually wins on size and ergonomics. XML still has real advantages where document-like, mixed content matters, and where schema validation, namespaces and transformation tooling are already part of the pipeline — publishing, enterprise integration, office document formats.
Can this validate against my XSD?
No. This checks well-formedness using the browser's XML parser. Schema validation needs the schema document and a validating processor; most browser parsers deliberately do not fetch or apply external schemas.
Privacy. Parsing happens in your browser. Your document is never uploaded, so it is safe to paste internal or customer data here.