XML validator

An XML validator answers two different questions

The first question is whether the document is well formed: one root element, every tag closed and nested in the right order, attribute values quoted, namespace prefixes that resolve, and no bare ampersand pretending to be an entity. That is pure syntax, it needs nothing but a parser, and this page answers it the moment you press the button — without downloading anything at all.

The second question is whether the document is valid against a schema: does it contain the elements an XSD says it must, in the order it says, with values of the types it declares? No browser ships an XML Schema processor, so that answer needs a real implementation. This page uses libxml2 compiled to WebAssembly, served from this site, and it is fetched only after you have supplied a schema. Check well-formedness all day and the engine is never requested.

Every finding, not just the first one

A parser that exists to transform a document can stop at the first thing it does not understand, because there is nothing useful it can do afterwards. A validator that stops there makes you fix one line, run again, fix the next line, and run again. This one lists every position the parser objected to, each with a line number, a column, the source line itself and a caret under the exact character. A document with four mismatched closing tags produces seven findings, and you can work through them in one pass.

Later findings in a badly broken document are often consequences of the first one — once a tag is left open, everything after it nests wrongly. The list is bounded and the receipt says how many further findings were counted but not printed, so a truncated list never looks like a complete one.

A DOCTYPE does not make a document invalid

DocBook, XHTML, Ant build files, Apple property lists and pre-2005 RSS all start with a <!DOCTYPE> declaration, and all of them can be perfectly well formed. Tools that refuse to look at such a file because they will not resolve its DTD are answering a different question than the one you asked. This page reports the DOCTYPE as a fact about the document, never resolves it, and still gives you the well-formedness verdict.

Not resolving it is deliberate. An external DTD is another file that would have to be fetched, and an internal subset can redefine entities in ways that change what the document means — which is the whole shape of the billion-laughs class of attacks. DTD validity is therefore not checked here, and the receipt says so rather than letting silence imply it passed.

The schema location inside your file is not fetched

Many documents name their schema in xsi:schemaLocation or xsi:noNamespaceSchemaLocation. Server-side validators follow that URL, and the retired freeformatter.com did exactly that. This page does not, and the reason is not squeamishness: the URL is a string that happens to be inside your file, not something you asked for. Following it would be a network request you never made, aimed at a host you may not control, from a page whose promise is that nothing leaves your browser.

What the receipt does instead is show you the declared location, so you know which schema the document claims to follow, and then you open that .xsd yourself. Paste it or pick the file; both paths are equivalent. Schemas that import or include other schema documents are the one case this cannot handle in a single step, because the imported files would have to be fetched too — combine them, or validate against the module you actually care about.

What the schema step can and cannot tell you

libxml2 implements XML Schema 1.0. Assertions, conditional type assignment and the facets introduced in XSD 1.1 are not evaluated; a schema that relies on them will usually fail to compile, and the result attributes that failure to the schema rather than to your document — an important difference when you are debugging one of the two. RELAX NG and Schematron are not run either.

Schema findings carry a line number and no column. That is libxml2 reporting what it knows: it tracks the line an element started on and nothing narrower. The well-formedness findings above them carry a line and a column because a different parser produces those and that parser counts characters. Guessing a column for a schema error — by searching the line for the element it names, say — would look more precise and be less true, so the receipt keeps the two lists apart and labels which is which.

When you want something other than a verdict

If the document is fine and you simply want it readable, the XML formatter re-indents or minifies it while leaving namespaces, mixed content and xml:space="preserve" alone. If the file is a sitemap, the sitemap validator adds the protocol rules a generic XML validator has no way to know about: the required namespace, absolute locations, W3C dates and the 50,000-entry and 50 MB ceilings. To produce XML from a spreadsheet export in the first place, CSV to XML builds it from named columns, and for the other common structured format the JSON validator answers the equivalent question — with the difference that JSON has no schema layer, so its version of "valid" is really a question about which dialect the document is written in.

If you have the document but no schema at all, that is a different question with a different answer: the XSD generator derives one from your example and, more importantly, lists which parts of it were measured and which had to be guessed — a derived schema is only as trustworthy as the example it came from.

Whatever you bring, it stays here. The document, the schema and the result are read, parsed and reported inside this tab; nothing is uploaded, nothing is stored, and no URL your file mentions is opened.