XML XSD Validator

The tool runs xmllint from libxml2 2.13, compiled to WebAssembly by the xmllint-wasm project, in a background worker in your browser. It is the same check as xmllint --noout --schema invoice.xsd invoice.xml on a command line. First libxml2 compiles the schema, including every file it imports or includes. Then it parses each XML file. Only a well-formed file is checked against the schema rules.

Each stage can stop the check, so the result tells you which stage failed:

libxml2's messages are precise but terse. These are the ones you'll meet most often, quoted as libxml2 prints them. The tool shows the same explanation next to each error it finds.

Names in curly brackets, such as {urn:example:invoice}line, are libxml2's way of writing an element together with its namespace. The tool splits them into the name and the namespace.

Load the valid example and delete xmlns="urn:example:invoice" from the root element. The tool warns before you run it, and libxml2 then reports a single error on line 2:

Nothing else in the file is checked, because the validator never found a declaration to start from. The schema declares targetNamespace="urn:example:invoice", so its invoice element is {urn:example:invoice}invoice. An invoice element in no namespace is a different name. Put the xmlns back and the file validates. Because the schema also sets elementFormDefault="qualified", the child elements must be in that namespace too, which the default xmlns on the root takes care of.

The same error appears when the root is simply the wrong element, for example a <line> fragment checked on its own, since only top-level xs:element declarations can be a document root.

Large schemas are split across files with xs:import (another namespace), xs:include (same namespace) and xs:redefine. The validator can't read your disk or the web, so add those files under Supporting schemas. Before validating, the tool reads every schemaLocation, matches it to an uploaded file by name and lists anything missing.

A missing xs:include stops the schema from compiling. A missing xs:import is only a warning ("Skipping the import"), but every type from that namespace is then undefined, so the errors appear later as "does not resolve to a(n) type definition". Files are matched by name only, so two different files that are both called common.xsd in different folders can't be used in the same run.

Many XML files name their schema with xsi:schemaLocation or xsi:noNamespaceSchemaLocation. The XSD specification treats these as hints that a processor may ignore, and xmllint does when it is given a schema to use. This tool checks every file against the schema you paste or upload, whatever the hint says. That means a typo in the hint, or a hint that points to a web address, can't change the result. It also means you must load the right schema yourself.

libxml2 implements XML Schema 1.0. Schemas written for XSD 1.1 fail to compile, usually with a confusing "The content is not valid" message, so the tool flags 1.1 features before you validate. These are the results from running each feature through the validator:

For XSD 1.1 schemas, use a 1.1 processor such as Saxon-EE or Apache Xerces-J with XSD 1.1 support.

The validator may use up to 1 GiB of memory. A 113 MB test file validated within that limit, where the old 64 MiB limit failed on a 24 MB one. Very large files are slow to edit in a text box, so upload them instead of pasting. If a file still runs out of memory, xmllint's --stream option on a command line validates without loading the whole document.

Uploaded files are decoded the way an XML parser reads them: a byte-order mark first, then the encoding in the XML declaration. UTF-8, UTF-16 and ISO-8859-1 or Windows-1252 files all display correctly. The text is then handed to libxml2 as UTF-8, with the declaration changed to match, so line numbers stay the same.

Files are processed in a Web Worker inside this page. Nothing is uploaded to a server, and the validator has no network access, so it can't fetch schemas or external entities.