XML Well-Formedness & XSD Validation

Updated: June 2026 · All guides

XML processing has two gates. Well-formedness means the document follows XML syntax rules — every tag closes, attributes are quoted, one root element exists. Validity (against an XSD schema) means the structure and data types match a contract. A document can be well-formed but invalid, or fail before you ever reach schema checks. This guide walks through both stages with fixes for the errors we see most often.

Well-formedness: syntax rules

Common parser errors and fixes:

Unclosed tag — Every <item> needs </item> or self-close <item/>
Ampersand in text — Write & not bare &
Multiple roots — Wrap siblings in one root element
Invalid characters — Control chars except tab/newline are forbidden
Attribute quoting — Values must use single or double quotes

Use XML Formatter after fixing syntax — it will refuse to pretty-print until the parser succeeds, which confirms well-formedness.

Example: well-formed but semantically wrong

<order id="abc">
  <line qty="2" sku="WIDGET"/>
  <line qty="x" sku="GADGET"/>
</order>

This parses. An XSD might require qty to be a positive integer and id to match a UUID pattern — qty="x" and id="abc" would fail validation with typed error messages.

What XSD adds

XML Schema Definition (XSD) can specify:

Required and optional elements, order, cardinality
Simple types: dates, decimals, enums, string patterns
Complex types: nested structures reused across elements
Default and fixed attribute values

Industries like healthcare (HL7), finance (ISO 20022), and government exchanges publish XSDs partners must follow. Validating before transmission avoids rejections at the gateway.

Minimal XSD snippet

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="order">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="line" maxOccurs="unbounded">
          <xs:complexType>
            <xs:attribute name="qty" type="xs:positiveInteger" use="required"/>
            <xs:attribute name="sku" type="xs:string" use="required"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="id" type="xs:token" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

Validation workflow in the browser

Open Validate XML
Paste or import your XML document
Paste XSD or import schema file
Read errors with line numbers — fix well-formedness issues first if the parser stops early
Re-run until clean

Like our JSON tools, validation executes locally. Large industry schemas and confidential payloads stay on your device.

Well-formedness vs validity checklist

Parser error on open? → Fix well-formedness
Parser OK but partner rejects file? → Validate against their XSD
XSD error on optional field? → Check namespace prefixes match instance document
Intermittent errors? → Compare versions with XML Diff

XSLT and downstream transforms

After validation, you may transform XML to HTML or another format with XSLT. Try stylesheets in XSLT Playground. Validate inputs first — transforms on malformed XML produce misleading output or runtime errors.

Reading parser error messages

Well-formedness errors usually include a line and column. Typical messages and fixes:

“Opening and ending tag mismatch” — find the unclosed element; XML Formatter stops at the first error
“EntityRef: expecting ';'” — bare & in text; escape as &
“Comment must not contain '--'” — illegal sequence inside 
“XML declaration allowed only at the start” — BOM or whitespace before <?xml

Fix errors top to bottom — the parser reports the first failure; later errors may disappear once the root cause is fixed.

Understanding XSD validation errors

Schema errors differ from parse errors. Examples:

“Element X is not allowed” — extra tag not in schema; remove or extend XSD
“Invalid value for type xs:positiveInteger” — qty="x" or negative number
“Missing child element Y” — required element absent; check order in xs:sequence
“Cannot find declaration for element Z” — namespace mismatch; align prefixes and target namespaces

Namespace tip: If XSD targets one namespace and your XML uses another (or none), validation fails even when tags “look” correct. Compare targetNamespace in XSD with xmlns on your root element.

DTD vs XSD (quick comparison)

Older systems use DTD (Document Type Definition); modern integrations prefer XSD. XSD supports rich types (dates, decimals, regex patterns) and is expressed in XML. DTDs are limited but still appear in legacy SGML-era pipelines. Our validator focuses on XSD; for DTD, check if your toolchain still requires it.

Large documents and performance

Multi-megabyte XML files validate locally without upload limits. If the browser feels slow, validate subtrees — extract the section under test — or format incrementally with XML Formatter after fixing syntax. For repeated CI validation, cache compiled schemas server-side; for ad-hoc debugging, browser validation is enough.

End-to-end workflow example

Receive partner XML file; paste into Validate XML
Fix well-formedness until parser succeeds
Load partner XSD; run schema validation
If rejected, use XML Diff against last known good sample
Query specific fields with XPath to confirm values
Transform to HTML report via XSLT Playground if needed

FAQ

Well-formed but invalid — can partners still reject it?

Yes. Trading partners enforce XSD strictly. Always validate against their published schema before submission.

Do I need both well-formedness and XSD checks?

Yes. Well-formedness is mandatory for any XML processor. XSD is optional but required when a contract specifies it.

Can I validate JSON with XSD?

No — use JSON Schema for JSON. Convert XML to JSON only if you accept semantic loss; validation rules do not transfer automatically.