Well-Formed vs Valid XML

Well-formedness and validity are two different questions about the same file, and conflating them is why "my XML is valid" so often means two incompatible things. Well-formedness is a property of syntax alone: every start tag has a matching end tag, elements nest without crossing, attribute values are quoted, entity references are declared, and there is exactly one root element. Any conforming XML parser can answer it from the document by itself, with no schema and nothing fetched from anywhere. Validity is a property of a document relative to a schema — an XSD or a DTD that declares which elements may appear, in what order, how many times, and what their text and attributes must look like. The two are ordered rather than parallel: a document can be flawlessly well-formed and still break every rule its schema defines, while a document that is not well-formed cannot be validated at all, because the parser never produces a tree to check. Well-formedness is the gate; validity is the contract behind it.

Well-formedness: the syntax contract

The rules for well-formedness are short and fixed, and they live in the XML 1.0 specification rather than in anything you write. A well-formed document has exactly one root element; every element that opens is closed, either with an end tag or as an empty-element tag; elements nest strictly, so <a><b></a></b> is not XML; attribute values are quoted and no attribute is repeated on one element; the characters < and & appear as markup or as escapes, never as raw text; and every entity reference resolves to a declaration. That is essentially the whole list. Because it needs nothing but the bytes in front of it, well-formedness is what every parser checks before it does anything else, and it is what a browser, an editor or a build step is doing when it says a file "isn't XML". A failure here is a hard stop: the specification requires a parser to report a fatal error and not attempt to recover, which is why one missing slash can take out a file that is otherwise perfect.

Validity: conformance to a schema

Validity asks the second question: given a schema, does this document obey it? The schema is where your domain lives — that an <order> contains one <customer> followed by one or more <line-item>, that @quantity is a positive integer, that <ship-date> is a date and not the string "soon". None of that is knowable from the document alone, which is why validation always takes two inputs. An XSD expresses these constraints with a type system and namespace awareness; a DTD, the older mechanism the XML specification itself defines validity against, expresses a subset of them. Either way the check is relative: the same document is valid against one schema and invalid against another, and a schema that declares nothing accepts almost anything. "Valid" on its own is therefore an incomplete claim — the useful form is always "valid against this schema".

Why a well-formed document can still be wrong

Consider a purchase order whose schema requires a <quantity> of type xs:positiveInteger and exactly one <customer>. A document that supplies <quantity>none</quantity>, omits the customer entirely, and adds a <notes> element the schema never declared is perfectly well-formed: the tags match, the nesting is clean, nothing is unescaped. A syntax check passes it without complaint. Against the schema it fails three separate ways — wrong simple type, missing required child, unexpected element — and only the schema-aware check can say so. This is the practical reason the two checks are worth keeping distinct in your head: a green result from a syntax checker is not evidence that a document is acceptable to the system that will consume it. It is evidence that the system will be able to parse it before rejecting it.

Schemas split across files, and what this tool does about it

Real schemas are often split up with xsd:import and xsd:include, and that is where a browser-based validator has to be honest. Nothing you paste here leaves your device, and that includes the files your schema points at: no network request is made for them. Fetching them automatically is not really an option a browser tool has anyway — a cross-origin request needs the host serving the schema to opt in with CORS headers, which the canonical schema hosts generally do not, and doing it at all would mean sending part of your work off the machine. The failure mode this avoids matters more than the limitation itself: libxml2, the engine underneath, quietly downgrades when it cannot resolve a reference and will report that a document "validates" when a whole imported vocabulary was missing. So instead of guessing, the XSD Validator withholds the verdict: the result reads cannot validate, it names the file it could not read, and it states plainly that it will not report "valid" when an unresolved reference could change the answer. One exception is bundled — the XML namespace schema, xml.xsd — so a schema importing that resolves and validates normally.

Which page answers which question?

If your question is "is this XML at all?", use the XML validator: paste one document and it reports well-formedness — matching tags, nesting, entities, a single root — with the parser's own error text. This is also the right page for checking that an .xsd file is itself well-formed XML, since a schema is an XML document like any other. If your question is "does this document obey that schema?", use the XSD validator: it takes two panes, the XSD on the left and the XML instance on the right, compiles the schema and then checks the document against it, reporting each conformance error with its line and the pane it came from. Leave the right pane empty and it checks the schema on its own instead, which answers "does my XSD compile?" without needing an instance. Conformance there is XSD 1.0 — the engine is libxml2 compiled to WebAssembly — so XSD 1.1 constructs such as xs:assert are reported as unsupported rather than silently mis-checked, and the xsi:schemaLocation hint inside a document is ignored in favour of the schema you actually pasted. Both pages run entirely in your browser.

Well-Formed vs Valid XML FAQ