formatter.input (XML)
Loading Editor...
formatter.output (XML)
Loading Editor...
XML has been powering enterprise systems, document formats, and web services for over two decades. In that time, developers have collectively spent an uncountable number of hours staring at errors like this:
Or worse — no error at all, because the downstream system silently accepted malformed XML and processed it incorrectly for weeks before anyone noticed.
Our XML Validator gives you something better: paste your XML and get an immediate, precise diagnosis. Not just "your XML is invalid" — but exactly which tag is unclosed, which attribute is unquoted, which character needs escaping, and on which line. Fix it in seconds, not hours.
XML has a two-tier validity model that confuses a surprising number of developers. Understanding it changes how you think about XML validation entirely.
A well-formed XML document follows the syntactic rules of the XML specification: every opening tag has a matching closing tag, tags are properly nested, attributes are quoted, there is exactly one root element, and special characters are correctly escaped. Any XML parser will reject a document that isn't well-formed — it won't even attempt to read the content.
A valid XML document is well-formed AND conforms to a schema — either a DTD (Document Type Definition) or an XSD (XML Schema Definition) — that specifies exactly which elements and attributes are allowed, in what order, with what data types. An XML document can be perfectly well-formed but still invalid against a schema if it contains unexpected elements, missing required attributes, or values of the wrong type.
What this tool validates: Our validator checks for well-formedness against the W3C XML 1.0 specification. If your XML isn't well-formed, nothing else matters — fix that first. For full schema validation against an XSD, you need a schema-aware validator, which is typically done server-side in tools like xmllint, Saxon, or within your IDE.
Most developers dealing with XML errors are dealing with well-formedness problems — the kind this tool catches completely. Schema violations are rarer and usually discovered during integration testing.
Every XML document submitted to our validator is checked against the following rules — in the order a real XML parser would encounter them:
If present, the XML declaration (<?xml version="1.0" encoding="UTF-8"?>) must be the very first content in the document — before any whitespace, before any elements, before anything. Even a single space before the declaration breaks it.
Every well-formed XML document must have exactly one root element that wraps all other elements. Multiple top-level elements, or no elements at all, are both invalid.
<!-- Invalid --> <user>Alice</user> <user>Bob</user>
<!-- Valid --> <users> <user>Alice</user> <user>Bob</user> </users>
Every opening tag must have a corresponding closing tag. Tags must be properly nested — a tag opened inside another tag must be closed before the parent tag closes.
<b><i>bold italic</b></i>
<b><i>bold italic</i></b>
XML tag names are case-sensitive. <User> and <user> are completely different elements. An opening <User> tag must be closed with </User>, not </user>.
All attribute values must be enclosed in quotes.
<book category=fiction>
<book category="fiction">
Five characters have special meaning in XML and must be escaped when used in element content or attribute values:
| Character | Escape | Used In |
|---|---|---|
| < | < | Element content, attributes |
| > | > | Element content |
| & | & | Element content, attributes |
| " | " | Attribute values |
| ' | ' | Attribute values |
The most common offender is & — every unescaped & is a parsing error.
Empty elements can be written as either a matched pair (<br></br>) or as a self-closing tag (<br/>). Both are valid.
Processing instructions (<?target data?>) and comments (<!-- comment -->) must be correctly formed. Comments cannot contain double dashes (--) within their content, and cannot end with --->.
Not all XML errors are equal. Some break parsers immediately. Others slip through and cause downstream damage.
This is the single most common XML error in production systems. Company names ("Johnson & Johnson"), URLs with query parameters, and SQL queries embedded in XML all contain raw ampersands that break parsers.
A missing namespace declaration causes namespace-aware parsers to reject the document even though the syntax looks fine.
If an XML document declares encoding="UTF-8" but the actual bytes are in ISO-8859-1 (Latin-1), parsers will reject it. This is common with XML generated by legacy systems or copied from Windows applications.
CDATA sections (<![CDATA[ ... ]]>) allow you to include content without escaping. But they cannot contain the string ]]> within their content (since that's the closing delimiter).
Some text editors save files with a UTF-8 Byte Order Mark (BOM) — three hidden bytes at the start of the file. Many XML parsers reject documents with a BOM because it appears before the XML declaration.
Payment processing systems, SWIFT messaging, and FIX protocol implementations all rely on XML. A malformed SWIFT message can fail to process a payment.
Patient records, lab results, and prescriptions transmitted as malformed XML can fail to process or be misattributed to the wrong patient.
EDI relies on XML for purchase orders and invoices. A malformed document can delay fulfillment and trigger supplier issues.
Court filings and tax submissions are often XML. Malformed submissions are typically rejected automatically, requiring resubmission.
Maven POM files, Spring configuration, and Android manifests are XML. A malformed file breaks the build for the entire team.
Our online validator is ideal for quick, ad-hoc validation. For systematic validation, here's how to integrate it:
Well-formed XML follows basic syntax rules (proper tag nesting, quoted attributes, etc.). Valid XML is well-formed AND conforms to a specific schema (DTD or XSD) that defines which elements are permitted. Our validator checks well-formedness.
Different parsers have different strictness. Some are lenient, others strict. The W3C spec requires strict parsing. If it fails here but works elsewhere, usage of a lenient parser is masking errors.
It usually means you have an unescaped & inside your content that the parser thinks is starting a special code. Replace bare & with &.
Yes. The validator handles XML with namespace declarations (xmlns) correctly and checks that prefixes are declared.
CDATA sections (<![CDATA[ ... ]]>) mark text to be ignored by the parser. Use them for embedding HTML, SQL, or code snippets with many special characters.
A Byte Order Mark (BOM) is a hidden character sequence some editors add to UTF-8 files. Parsers fail if it's before the XML declaration. Save as 'UTF-8 without BOM'.
UTF-8 is best and the default. Declare it: <?xml version="1.0" encoding="UTF-8"?>. Avoid legacy encodings like Windows-1252 unless absolutely necessary.
Yes. SOAP messages are XML. Paste the whole envelope to check well-formedness. Schema validation is a separate step.
Not currently — it checks well-formedness. Full schema validation requires a schema-aware tool like xmllint or Java JAXP.
There is no hard limit. All processing happens in your browser. For very large files, use the file upload option.
Paste your XML above — malformed, minified, or fresh from a legacy system that hasn't been touched in years — and know in seconds exactly what's wrong and where to fix it.