XML Validator Online 2026 - Check Well-Formedness & Schema (XSD)
Validate XML syntax and structure instantly. Detect well-formedness errors with detailed reporting. 100% Private & Free.
Key Features
- ✅ Real-time validation
- ✅ Error line detection
- ✅ Well-formed check
- ✅ Detailed error messages
How to Use
- Paste or upload your XML file
- Optionally select validation level (well-formed, DTD, XSD)
- If using schema validation, upload DTD or XSD file
- Click Validate to start validation
- Review validation results and error messages
- Errors show exact line numbers for debugging
- Fix issues in your XML
- Re-validate after making corrections
Expert FAQ
- What's the actual difference between "well-formed" and "valid" XML?
Well-formed means the document obeys XML's own syntax rules — every tag closed, properly nested, exactly one root element, attribute values quoted. Valid means it additionally conforms to a specific schema (DTD or XSD) that defines which elements/attributes are allowed and in what order. A document can be perfectly well-formed XML and still be invalid against a given schema (e.g. missing a required element) — this validator checks well-formedness always, and schema validity only if you supply a DTD/XSD. - My tag is written exactly the same way twice — <Item> and <item> — why does it say mismatched tags?
Unlike HTML, XML is case-sensitive by design: <Item> and <item> are different tag names, full stop. A document with <Item>...</item> is not well-formed, even though many HTML parsers would tolerate the equivalent case mismatch. This is one of the most common errors when XML is hand-edited or generated by code that doesn't enforce consistent casing. - I have an attribute value containing a raw & character (like a URL with a query string) — does that break validation?
Yes — a bare & is illegal anywhere in XML content or attribute values outside of an entity reference; it must be written as &. This is the single most frequent well-formedness violation in real-world XML, especially in URLs (?a=1&b=2) pasted directly into attribute values without escaping. The validator flags the exact position of the offending ampersand. - Does it catch encoding mismatches — like a file declared as UTF-8 that actually contains Latin-1 bytes?
Yes. The XML prolog's encoding declaration (<?xml version="1.0" encoding="UTF-8"?>) is a promise about how to decode the bytes that follow; if the actual byte sequence isn't valid UTF-8 (common when a file was saved by an editor defaulting to a different encoding), strict parsers reject the document outright rather than guessing. This validator surfaces that mismatch rather than silently substituting replacement characters, since silent substitution would mask real data corruption.
Technical Details
XML validation operates on two distinct levels that are worth keeping separate. "Well-formed" is a syntax-only check: matched and properly nested tags, exactly one root element, quoted attribute values, and correctly escaped reserved characters (a bare & or < outside of markup is illegal and must be written & / <). Every well-formedness check this validator performs is spec-mandated and has no configuration — there's no such thing as "slightly invalid" XML the way there's "mostly working" HTML, since XML parsers are required by spec to reject anything that isn't well-formed rather than attempt error recovery. "Valid" is a stricter, optional second layer: conformance to a DTD or XSD schema that constrains which elements and attributes are permitted, their order, cardinality, and data types. A document can be well-formed but invalid (using an element the schema doesn't define) or, much less commonly discussed, schema-valid documents can still contain well-formedness violations if the schema check is run by a lenient tool that doesn't also enforce base syntax — this validator always checks well-formedness first regardless of whether a schema is supplied. Two error categories account for a large share of real-world failures: case-sensitivity mismatches (XML, unlike HTML, treats <Item> and <item> as different elements — no implicit normalization), and unescaped reserved characters, most often a literal & inside a URL pasted into an attribute value. A third, encoding declarations that don't match the document's actual byte encoding, causes parsers to reject the file outright rather than silently misinterpret characters — this validator treats that as a hard error rather than attempting lossy recovery. Once your XML validates, the XML Formatter can clean up its presentation, or convert it with XML to JSON.