XSD Validator

A well-formed XML document can still be wrong: missing a required element, using the wrong data type for an attribute, or having elements in the wrong order. XSD (XML Schema Definition) describes exactly what the document should look like. This validator pairs your XML with its XSD, runs the W3C XML Schema validator and lists every violation with line, element and the specific constraint that was broken.

How to validate XML against XSD

  1. 1

    Paste both files

    XML on one side, XSD schema on the other. Multiple schemas can be pasted together.

  2. 2

    Run validation

    The parser matches elements, attributes and types against schema declarations.

  3. 3

    Review errors

    Each violation shows element path, expected constraint and actual value.

  4. 4

    Fix and revalidate

    Edit in place and re-run without reloading.

What XSD checks

  • Element names and cardinality: required, optional, min/max occurrences.
  • Element order: sequence, choice, all.
  • Attribute presence and type: required vs optional, default values, fixed values.
  • Data types: xs:string, xs:integer, xs:decimal, xs:dateTime, xs:boolean, xs:anyURI, custom.
  • Restrictions: min/max length, enumerations, regex patterns, min/max values.
  • Referential integrity: xs:key, xs:keyref, xs:unique for cross-element constraints.

Typical errors

Error XSD constraint
Missing required element <email> minOccurs="1"
Too many <phone> elements maxOccurs="2" exceeded
Value “abc” is not a valid integer type="xs:integer"
Value “[email protected]” does not match pattern xs:pattern on xs:string
Elements out of order xs:sequence
Unknown element <foo> Not declared in the schema
Duplicate key xs:unique violation

Choosing between XSD and alternatives

  • XSD: W3C standard, verbose, powerful, widely supported. First choice for enterprise XML.
  • RELAX NG: simpler syntax, equally expressive. Popular in documentation formats (DocBook, TEI).
  • Schematron: rule-based, runs XPath assertions against the document. Good for business rules beyond structure.
  • DTD: older, much less expressive. Still in use for HTML historical compatibility.

Many projects use XSD for structure and Schematron for complex cross-field rules.

Common gotchas

  • Namespaces must match. If the XSD declares targetNamespace="http://example.com" but the XML does not use that namespace, validation fails with “no declaration found”.
  • xs:anyType is not a magic escape. It matches anything but gives you no validation at all.
  • Default values apply only when the attribute is absent. An explicit empty value (attr="") does not get the default.
  • Whitespace handling varies by type. xs:string preserves it, xs:token collapses it, xs:normalizedString replaces tabs/newlines with spaces.

Debugging workflow

  1. Validate without schema first (well-formedness check). Fix any parse errors.
  2. Then validate against schema.
  3. Focus on the first error. XSD validators sometimes cascade errors; the first one is usually the most actionable.
  4. Use XPath to locate the offending element in large documents.

Frequently Asked Questions

No. Paste them separately, or reference the schema via xsi:schemaLocation in the XML. Most tools support both approaches.

Yes. When elements from different namespaces appear, each needs its own schema. Paste all of them; the validator loads them all.

XSD 1.0. The underlying libxml engine does not implement XSD 1.1, so 1.1-only features such as assertions, conditional types and open content are not enforced.

No. Your XML and schema are sent to the server only to run the validation for that single request; they are not stored or logged afterwards.

Related Tools

Tool available in other languages