break your xlsx parser

How to use these fixtures

1. Download a single file, or take all 13 as a ZIP — the archive includes a README explaining every file.
2. Run each one through your own XLSX import path.
3. Come back and record whether your parser handled it. Results are kept in your browser, so leaving the page is expected.
4. Copy the damage report as Markdown and paste it into a pull request or an issue.

Why XLSX parsers fail

An .xlsx file is a ZIP archive containing XML parts. That single fact is the whole story: it inherits the failure modes of both formats, and adds its own on top — shared string tables that lie about their size, cells whose declared type disagrees with their content, and a dimension header that readers are tempted to allocate from.

The packaging is what makes it dangerous. These are files that pass an extension check, pass a content-type sniff, and in several cases open correctly in Excel — while carrying an entity bomb in the worksheet or a traversal path in the archive. The parser you need to harden is usually one inside a library you did not write.

Questions

Why does XLSX need its own pack when you already have ZIP and XML?

Because an .xlsx file is a ZIP archive of XML parts, it inherits every failure mode of both — a traversal path works here exactly as in a plain archive, and an entity expansion exactly as in plain XML. What changes is the context: a developer who would never hand untrusted XML to a lenient parser will happily pass an uploaded spreadsheet to a library, because a spreadsheet feels like structured data rather than an archive full of attacker-controlled markup. It is both.

Will these open in Excel?

Several will, which is the point. The Zip Slip fixture is a completely valid workbook that happens to carry one extra archive entry, so a file-type check, a virus scan and Excel itself all pass it. The damage happens in whatever unpacks it to a temporary directory before parsing.

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.