DEV Community: Alex Babintsev

Why is my XML valid but still rejected?

Alex Babintsev — Fri, 30 Oct 2026 00:00:00 +0000

"But it's valid XML" is the most common reply to a rejected file, and it is usually true. It just answers a different question from the one the receiver asked. "Valid" covers at least four separate checks, each stricter than the one before, and a file can pass one and fail the next.

To show where each one draws its line, I took a small UBL invoice that passes the XML Schema and all of the EN 16931 business rules, then broke it in different ways. Every message below is real output from libxml2 and the official rule sets, not a paraphrase.

Level 1: is it XML at all

The first check is whether the file is well-formed: tags closed and properly nested, one root element, attribute values in quotes, special characters escaped. No schema is involved. A browser that shows the file as a tree has only done this much.

Change the item name to Toner & drum and the parser stops:

line 53 xmlParseEntityRef: no name

An ampersand starts an entity reference in XML, so a bare one in text has to be written &. This is almost always a sign that the XML was built by joining strings rather than with an XML library, which would have escaped it. Other errors of this kind are a tag closed in the wrong order, text after the root element and a file cut off halfway.

A well-formedness error stops everything. The parser cannot tell where the damage ends, so there is no schema check and no business rule check until it is fixed. If a validator reports exactly one error and it is one of these, that does not mean the rest of the file is fine; nothing else has been looked at yet.

Level 2: does it follow its schema

A schema describes what the document may contain: which elements, in what order, how many times, and of what type. For an invoice that is an XSD, but DTD and RelaxNG do the same job for other documents. Here the parser checks the file against UBL 2.1's UBL-Invoice-2.1.xsd.

Write the issue date the way people write dates in Germany:

line 7 Element 'cbc:IssueDate': '30.10.2026' is not a valid value of the atomic type 'xs:date'.

xs:date is 2026-10-30 and nothing else, whatever the locale. Or keep every value right and swap two elements, putting the currency code before the invoice type code:

line 9 Element 'cbc:InvoiceTypeCode': This element is not expected. Expected is one of ( cbc:TaxCurrencyCode, cbc:PricingCurrencyCode, cbc:PaymentCurrencyCode, … ).

XSD sequences are ordered, so the same elements in another order are a different document. The message names the element it found and lists what it would have accepted at that point; the element you meant is somewhere further down the schema. Both messages have their own pages: not a valid value of the atomic type and this element is not expected.

This is where most people stop, and for a lot of XML it is the right place to stop: configuration files, data feeds, a DTD-based publishing format. The XSD, DTD and RelaxNG guides cover this level for each schema language.

What a schema cannot do is relate one value to another. It can say that TaxInclusiveAmount is a decimal amount. It cannot say that it must equal the amount without tax plus the tax.

Level 3: does it follow the business rules

That job belongs to business rules, usually written in Schematron: XPath assertions over the whole document, each with an id and a message. For invoices in Europe the base set is EN 16931, published by CEN: over 200 BR- rules on the invoice's content, plus syntax rules for UBL and CII.

Add 0.19 to the total with VAT (and to the amount due, so the two still agree) and the file is still schema-valid. The rules are not satisfied:

BR-CO-15 Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).

100.00 + 19.00 is not 119.19. In real invoices this is usually a rounding difference: VAT rounded per line, then summed, against VAT computed once on the total.

Or remove the buyer's legal name. UBL makes cac:PartyLegalEntity optional, because UBL is a general format used for much more than invoices. EN 16931 decides what an invoice needs:

BR-07 An Invoice shall contain the Buyer name (BT-44).

The BT numbers are EN 16931's business terms, the same field whatever the syntax: BT-44 is cac:PartyLegalEntity/cbc:RegistrationName in UBL and ram:BuyerTradeParty/ram:Name in CII. Each rule has a page explaining what it checks and how to fix it, for example BR-CO-15 and BR-07.

One practical consequence: business rules only make sense on a document that matches its schema, so xmlvalid runs them after the schema check passes. Fix the last schema error and a new batch of findings can appear. That is not the validator moving the goalposts; those rules simply had not run yet.

Level 4: does it follow the receiver's rules

EN 16931 is the common core. Most of the time the invoice is sent under a national or network profile that adds its own rules on top: XRechnung in Germany, Peppol BIS across Europe and beyond, CIUS-RO in Romania, France's CTC rules.

I took the invoice from the start, which passes both levels above with no findings, changed only its CustomizationID to say it is an XRechnung 3.0, and ran KoSIT's XRechnung rules on it. Ten errors and one warning:

Rule	What it wants
BR-DE-1	Payment instructions (BG-16)
BR-DE-2	A seller contact (BG-6)
BR-DE-3, BR-DE-4	The seller's city and post code
BR-DE-8, BR-DE-9	The buyer's city and post code
BR-DE-15	The buyer reference (BT-10), where German public buyers expect their Leitweg-ID
PEPPOL-EN16931-R001	A business process (BT-23)
PEPPOL-EN16931-R010, R020	Electronic addresses for buyer and seller
BR-DE-TMP-32 (warning)	A delivery date or invoicing period

None of these are mistakes as far as EN 16931 is concerned; they are fields that Germany's public buyers require, which the European standard leaves optional. KoSIT's messages are in German ("Das Element "Buyer reference" (BT-10) muss übermittelt werden."), which is another small surprise for anyone sending an XRechnung from outside Germany.

The rule set is chosen by the CustomizationID (BT-24). A file that claims the wrong profile is checked against the wrong rules, and a validator set to plain EN 16931 will happily pass an invoice the receiver then rejects. When you open an e-invoice in the validator, it reads BT-24 and picks the matching profile from the schema catalog for that reason.

Level 5: what no file check can see

Some rejections have nothing to do with the file's structure, and no validator, ours included, can predict them:

Registries. Whether the Leitweg-ID, the Peppol participant id or the VAT number exists and belongs to the right party. A correctly formed id can still be unknown to the receiver.
State. Duplicate invoice numbers, a purchase order that has already been invoiced, a credit note for an invoice the receiver never saw.
The receiver's own policy. Purchase order numbers required by one company and not by another, attachments in a format their system cannot open, size limits of the platform in between.
Clearance systems. Italy's SdI, Spain's VERI*FACTU and Mexico's CFDI check some things against government records at submission time. A validator can only cover the checks that need nothing but the file.

If a file passes levels 1 to 4 and is still rejected, the rejection message itself, not a validator, is the place to look.

Reading a rejection

The wording of the message usually tells you which level failed:

The message mentions	Level	Where to look
`parser error`, `xmlParseEntityRef`, `Opening and ending tag mismatch`	1, well-formedness	The line it names, or the code that wrote the XML
`Element '…': This element is not expected`, `not a valid value of the atomic type`, `cvc-complex-type.2.4.a` (Java)	2, schema	The schema and the element order
A rule id such as `BR-CO-15`, `BR-07`, `BR-S-08`	3, EN 16931	The rule's page; usually amounts or a missing field
`BR-DE-…`, `PEPPOL-EN16931-…`, `BR-FR-…`, `BR-RO-…`	4, the profile	The profile's documentation and the `CustomizationID`
A duplicate, an unknown id, something about the account or the order	5, the receiver	The receiver

Java and .NET word the same schema problems differently from libxml2. The error guide lists their versions alongside, so cvc-complex-type.2.4.a and This element is not expected lead to the same explanation.

Try it

The broken invoices from this post are easy to recreate: open the EN 16931 example or the XRechnung one in the validator, change a total or a date, and run it. It checks the schema and the profile's business rules together, in the browser, so the invoice is not uploaded anywhere.

Validating a 5 GB XML file in the browser

Alex Babintsev — Fri, 23 Oct 2026 00:00:00 +0000

Most online XML validators stop at a few megabytes. They upload the file, parse it into a tree on the server and walk the tree against the schema. That is fine for a config file and hopeless for a 2 GB data export, a year of bank statements or a product feed.

xmlvalid validates in the browser instead: the document never leaves the machine. To see how far that goes, I built a 5.2 GB file (5,242,879,782 bytes) out of a book catalog, broke one <year> on line 38,269,200 so it read 20x5, and opened it in the validator with its XSD. Sixty-six seconds later the page said:

Document is invalid: 1 issue
line 38,269,200 Element 'year': '20x5' is not a valid value of the atomic type 'xs:gYear'.

The tab's memory stayed flat the whole time. Here is how that works, and the few places where size still bites.

Why a tree does not work

The obvious way to validate XML in JavaScript is to read the file into a string and hand it to a parser. Two walls stand in the way long before 5 GB:

Strings. V8 caps a string at 2²⁹ characters, a little over 500 million, so file.text() fails on anything near a gigabyte.
Memory. A WebAssembly module compiled for 32 bits addresses at most 4 GB, and Emscripten's default ceiling is 2 GB. A DOM of the document is several times the document's size anyway.

So the document has to stream: read a piece, validate it, forget it, read the next one. Memory then depends on how deep the document nests, not on how long it is.

A streaming validator

libxml2 has done this for twenty years. Its xmlTextReader is a pull parser that can validate against XSD, RelaxNG or a DTD while it reads, and it frees each node once the reader has moved past it. It gets its bytes from whatever you give it: a file, a socket, or a callback.

The engine behind xmlvalid is a small Rust program around that reader. The same code runs natively on the server (for the API and the command-line client) and, compiled with Emscripten, in the browser. In the browser build the byte source is a function the page provides:

struct JsReader;

impl Read for JsReader {
    fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> {
        match unsafe { xv_js_read(buf.as_mut_ptr(), buf.len()) } {
            n if n >= 0 => Ok(n as usize),
            _ => Err(io::Error::other("host read failed")),
        }
    }
}

xv_js_read is a two-line Emscripten library function that calls back into JavaScript. libxml2 asks for a few kilobytes at a time and never sees more than that.

Feeding it from a File

The engine runs in a Web Worker, which matters for two reasons: the page stays responsive, and workers have FileReaderSync. libxml2's read callback is synchronous, and in a worker a Blob can be read synchronously, so there is no need for Asyncify or SharedArrayBuffer tricks:

const reader = new FileReaderSync();
const CHUNK = 1024 * 1024;

function byteReader(blob) {
    let offset = 0;
    let buffer = new Uint8Array(0);

    return (len) => {
        if (!buffer.length) {
            if (offset >= blob.size) return null;
            const end = Math.min(offset + Math.max(len, CHUNK), blob.size);
            buffer = new Uint8Array(reader.readAsArrayBuffer(blob.slice(offset, end)));
            offset = end;
        }
        const out = buffer.subarray(0, len);
        buffer = buffer.subarray(out.length);
        return out;
    };
}

blob.slice() does not read anything; it only describes a range of the file. Each readAsArrayBuffer call has a fixed cost, so the reader takes a megabyte at a time and serves libxml2's small requests from it. The callback copies the bytes into the module's heap with HEAPU8.set and returns the count; zero means end of file. The engine's heap stays around 20 MB whether the file is 5 MB or 5 GB.

Progress and errors go the other way as JSON lines, posted to the page as they happen, so the first error shows up while the rest of the file is still being read.

Things that break past 4 GB

Streaming removes the obvious limit and leaves a few quieter ones:

Counters. In wasm32 usize is 32 bits. Anything that counts bytes in it wraps at 4 GB, so the engine's byte and error counters are u64, and the file size crosses from JavaScript as a double, exact up to 2⁵³.
Line numbers. libxml2 keeps a node's line number in 16 bits. The engine passes XML_PARSE_BIG_LINES, which tells it to keep the real number past line 65,535, so an error on line 38 million says so.
Huge text. By default libxml2 refuses a single text node over 10 MB, a guard against hostile input. XML_PARSE_HUGE raises that to 1 GB, which is the one hard limit left: one text node, not the document.
Encodings. The browser build of libxml2 has no iconv, so a document in windows-1251 or Shift_JIS is transcoded to UTF-8 with a streaming TextDecoder on the way in, and its XML declaration rewritten to match. Line numbers stay the same.

The numbers

Same 5.2 GB file and XSD, same Mac:

Engine	Time	Throughput	Memory
Native (Rust + libxml2)	42 s	118 MB/s	4 MB resident
Browser (WebAssembly, headless Chromium)	66 s	79 MB/s	flat, about 20 MB of heap

The browser time is from the click to the verdict on the page, so it includes the worker, the copies into the heap and the page updating its progress bar. WebAssembly at two thirds of native speed is about what you would expect for a parser.

Where size still hurts

Two things do not stream as nicely.

Business rules. E-invoices are checked against Schematron rules (EN 16931, Peppol, XRechnung) after the schema. Those are XSLT, run with SaxonJS, and XSLT wants the whole document as a tree. That costs about 2.7 seconds per megabyte of invoice, and a 50 MB invoice takes a gigabyte of memory, so the rules stop at 50 MB. Real invoices are a few hundred kilobytes; the large ones are almost always a PDF attachment in base64, so past 50 MB those runs are cut to a stub before the rules see the document.

Big text nodes. Those base64 attachments were also where libxml2 itself slowed down: validating a single large text node against XSD took time quadratic in its length, 12 seconds for a 30 MB attachment. We patched it (now 0.09 seconds) and sent the fix upstream; that is a story for another post.

Try it

The validator is at xmlvalid.com/validate. It takes files up to 50 MB without an account and up to 1 GB with a free one. The 1 GB is where we drew the line for the page, not where the engine stops: if you need to check something larger, write to us.