XML is rigorously specified, which makes its failure modes the opposite of CSV's. The spec is clear; the bugs come from parsers being too accommodating. Entity expansion and external entity resolution are both conformant features, enabled by default in several widely used parsers, and wanted by almost no application.
The rest are the cases where a tolerant parser silently restructures your document. XML has no error recovery by design — unlike HTML, where leniency is correct. A parser that repairs a mismatched tag or picks a winner from duplicate attributes is inventing your data for you, and it does so without raising anything.
- Why do the entity fixtures matter?
- Entity expansion and external entity resolution are both conformant XML features that almost no application actually wants enabled. If your parser resolves them, any XML upload becomes a denial-of-service vector or a file-disclosure vector. Checking that they are disabled is the standard hardening step for every XML parser, and these two fixtures are how you check.
- Will the entity expansion fixture hang my machine?
- No. The classic billion-laughs file uses nine levels of nesting and expands to billions of nodes. This one uses four levels and expands to roughly ten thousand, which demonstrates the behaviour without being a real denial of service against the machine you are testing from. If your parser expands this one, the full-size version would take your service down.
- Does the external entity fixture read a real file?
- No. The canonical version of that test points at /etc/passwd. This one points at a path that does not exist, which proves the same thing — if your parser attempts resolution at all, the error it raises will name that path — without the fixture reading anything sensitive.
- Are these files dangerous?
- No. They are inert test files for checking your own import pipeline. Nothing here executes on its own — the fixtures that model injection or traversal exist so you can verify your own code rejects them, and the resource-exhaustion ones are deliberately scaled down so they demonstrate the behaviour without taking down the machine you are testing from.
- Why does the page show raw bytes?
- Because most of these cases are invisible in a text preview. A byte order mark renders as nothing, a bare carriage return looks identical to a CRLF, and a NUL looks like the end of the string. The hex view highlights exactly which bytes matter and explains each one when you hover it.
- Does my pass/fail progress get saved?
- Yes, in your own browser only, and separately for each format. The workflow expects you to leave the page, run a fixture through your parser, and come back — so results persist locally. Nothing is uploaded, and clearing site data clears them.
- Is this free?
- Yes. Every fixture is generated in your browser, with no signup and no upload.