About

They upload your document

Browsers cannot validate XML against a schema on their own, so most free tools solve that by sending your file to a server. Once that decision is made it tends to apply to everything, including the plain syntax check that never needed a server at all.

The people using an XML validator are frequently debugging a live integration. The document in front of them is a SOAP envelope with an authorisation header, or a config file with a connection string, or a payload containing customer records. Pasting that into an unfamiliar third-party service is a bad idea and is often against the policy they work under, but the alternative is not obvious when every result on the first page does the same thing.

Everything here runs in your browser tab, including schema validation. The privacy page explains how to verify that in about thirty seconds with your browser's network panel, which is more convincing than any assurance we could write.

They report one error and stop

Browser parsers halt at the first failure and describe it in the vocabulary of whoever wrote the parser. An unescaped ampersand becomes xmlParseEntityRef: no name in libxml2 and EntityRef: expecting ';' in Firefox. Neither mentions ampersands, escaping, or the query string that almost certainly caused it. Neither tells you the column.

That is why the validator here is a hand-written scanner rather than a call to the browser's parser. It recovers after a failure and keeps going, so one pass finds the unquoted attribute on line 4, the raw ampersand on line 12 and the unclosed tag at the end. Each report names the problem in ordinary words, gives an exact line and column, suggests what to write instead, and links to a page explaining the cause.

Those pages carry the equivalent message from six other parsers, because the string you paste into a search box when your Java build fails is not the string a browser would have shown you.

They conflate well-formed with valid

These are different checks answering different questions, and treating them as one is why people end up confused about why a system rejected a document their validator called fine. Well-formed means the syntax is correct. Valid means well-formed and also conforming to a schema. Here they are separate, labelled, and a clean syntax check says so explicitly rather than showing a green tick that could be mistaken for the other thing.

What this site will not do

• No advertising, and no space reserved for it later.
• No signup, no account, no rate limit, no captcha.
• No file size limit other than the point at which your own browser struggles.
• No cookie banner, because there are no cookies.
• No newsletter modal, no chat bubble, no feedback tab.
• No analytics that can see the editor. Ever.

Most of those are worth more to the people using this than anything that could be put in their place.

How it is built

Astro with static output, deployed to Cloudflare Pages. The XML engine is written from scratch: a single-pass scanner that reports every problem with a position, plus a catalogue of error definitions that drives both the tool's messages and the explainer pages, which is what stops the two drifting apart.

Schema validation uses libxml2 compiled to WebAssembly, running in a Web Worker so a large document does not freeze the page. It is loaded only when you ask for it, because it is around 480 KB and most visits never need it. XPath and XSLT use the browser's own engines where they exist, which costs nothing; the XSLT tool falls back to a WebAssembly build when Chrome removes its native processor in November 2026.

Content pages ship no JavaScript at all.

Corrections

The articles here make specific claims about specifications and about how particular parsers behave. If one of them is wrong, that is worth fixing properly rather than quietly. Write to [email protected] and say what is wrong and where.