XML Validator Online — Free XML Syntax Checker

Check XML for well-formedness — matched tags, properly quoted attributes, escaped entities, and a single root element. 100% in your browser. Note: schema validation (DTD/XSD) is a separate concept and not covered here.

Input XML

Validation Result

What is an XML Validator?

An XML validator in the well-formedness sense parses an XML document and reports any errors that would prevent any conforming XML processor — DOMParser, libxml2, .NET XmlReader, Java SAX — from accepting the file. It does not check the content against a schema; it confirms the syntax is legal XML.

Well-formedness is the floor every XML document must clear before any further processing — schema validation, XSLT, XPath queries, or application logic. Catching well-formedness errors at paste time (this tool) saves the much longer feedback loops of CI logs and runtime exceptions. The OpenFormatter XML validator runs in JavaScript on your machine — paste, click, see the line of the error, fix it, re-run.

How to validate XML online — 4 steps

Paste your XML. Drop a SOAP envelope, RSS feed, or any .xml file into the Input panel. Click Load Sample to try a demo order document.
Click Validate. The validator parses the XML client-side via DOMParser and either confirms well-formedness or surfaces the first parse error.
Read the error. Browser parser messages include the line and column of the failure (e.g. error on line 12 at column 5: Opening and ending tag mismatch). Fix and re-run.
Inspect document stats. On success, the validator reports the root element name, total element count, and max nesting depth.

Common well-formedness errors

1. Mismatched tags

Every opening tag must have a closing tag with the exact same name (XML is case-sensitive).

<!-- Invalid: case mismatch -->
<Order>...</order>

<!-- Valid -->
<Order>...</Order>

2. Unescaped ampersand

A bare & in element text or attribute values is the most common XML error in production data.

<!-- Invalid -->
<email>jane&co@example.com</email>

<!-- Valid -->
<email>jane&amp;co@example.com</email>

3. Multiple root elements

XML allows exactly one document element. Wrap multiple top-level items in a container.

<!-- Invalid -->
<order>...</order>
<order>...</order>

<!-- Valid -->
<orders>
  <order>...</order>
  <order>...</order>
</orders>

Well-Formedness Check

Matched tags, proper nesting, quoted attributes, escaped entities, single root — every rule from W3C XML 1.0 §2.1 is enforced.

Precise Error Location

Browser parser messages include line and column numbers, so you can jump straight to the problem in your editor.

Client-Side Only

Validation runs in JavaScript on your machine. SOAP envelopes with secrets, signed payloads, and PII never leave the browser.

Common use cases

check_circleValidating SOAP request envelopes before submitting to a web service
check_circleCatching unescaped ampersands in customer data exports before processing
check_circleChecking RSS, Atom, and podcast feed XML for syntax errors before publishing
check_circleVerifying hand-edited XML config files (Spring, log4j, .NET) before deployment
check_circleValidating XLIFF translation bundles before localization vendor handoff
check_circleChecking XML output from code generators, ORMs, and JAXB before integration
check_circleVerifying SAML assertions and WS-Security headers parse cleanly
check_circleValidating XML message-bus payloads from TIBCO, IBM MQ, or RabbitMQ

Well-formed vs schema-valid — a key distinction

XML has two layers of correctness. Well-formedness (this tool) is the universal floor: matched tags, valid syntax, escaped entities. Every XML document must be well-formed before anything else can happen. Schema validity goes further — it confirms the document conforms to a specific DTD, XSD, or RELAX NG schema, meaning the right elements appear in the right order with the right types. Schema validation is document-type-specific and requires the schema definitions; tools like xmllint --schema, Saxon, or your XML library's built-in validator handle that. Pair this validator with schema validation in your build pipeline for full coverage.

Need to do more than validate?

Format, view, parse, or convert XML — all browser-side, all free.

XML Formatter XML Viewer XML to JSON

Frequently Asked Questions

What does this validator actually check?

Well-formedness, as defined by the W3C XML 1.0 specification: every opening tag has a matching closing tag, elements are properly nested, attribute values are quoted, the five reserved characters (& < > " ') are escaped where required, and the document has exactly one root element. It does not check semantic correctness against a DTD or XSD schema — that is a separate concept covered below.

What is the difference between well-formedness and schema validity?

Well-formed = the document parses cleanly as XML. Schema-valid = the document also conforms to a DTD, XSD, or RELAX NG schema, meaning the right elements appear in the right order with the right attribute types. Most documents need both, but they are checked separately. This tool covers well-formedness; for XSD validation use xmllint, Saxon, or your application's built-in schema validator.

What are the most common errors the validator catches?

Five recurring issues. (1) Mismatched tags — opening <Order> with closing </order> or no close at all. (2) Unescaped ampersands — & must be written as & in element text and attribute values. (3) Improperly quoted attributes — value missing quotes, or mixing single and double quotes. (4) Multiple root elements — XML allows exactly one document element. (5) Invalid characters — control codes, non-XML Unicode codepoints.

How do I escape special characters in XML?

Five characters need escaping: & becomes &, < becomes <, > becomes > (in CDATA-ending contexts), " becomes " (inside double-quoted attribute values), and ' becomes ' (inside single-quoted attribute values). Alternatively, wrap large blocks of literal content in <![CDATA[ ... ]]> to bypass escaping entirely.

Why does my SOAP envelope fail validation when the server accepts it?

Two common reasons. First, copy/paste from logs sometimes mangles the XML declaration or strips the trailing close tag. Paste the full envelope including the <?xml ... ?> line. Second, BOM characters at the start of the document — invisible bytes that some editors insert. Re-save the file as UTF-8 without BOM and validate again.

Does the validator check XML namespaces?

It checks namespace syntax — that prefixed elements (soap:Body) have a corresponding xmlns:soap declaration somewhere up the tree, and that xmlns attribute values look like URIs. It does not check that the namespace URI matches a real schema; that is schema validation, which requires the schema definitions.

Can I validate XML against a DTD or XSD here?

No — DTD and XSD validation are deliberately out of scope. They require the schema definitions (often hundreds of KB of XSD), they enforce semantic rules specific to one document type (a Pod, a Compose service, an Atom feed), and they are best done in your build pipeline. Use xmllint --schema or your XML library's schema validator. This tool covers the universal first step: well-formedness.

Is my XML uploaded to your servers?

No. Validation runs entirely in JavaScript in your browser using the native DOMParser. SOAP envelopes with credentials, signed payloads, or sensitive business data never leave the device. Open DevTools → Network and confirm: clicking Validate produces zero network traffic.