blobforge

Break free while in beta

files that break parsers

Every file generator makes clean, valid data — including ours. Break does the opposite. 81 files engineered to fail, each isolating exactly one way real files break real parsers, with the correct behaviour documented beside it.

So when your importer chokes, you know which behaviour is wrong — not just that something broke.

81fixtures
6formats
23critical

CSV

19

An underspecified format. RFC 4180 is silent on encoding, line endings and stray quotes, so parsers disagree and files silently change as they move between tools.

Open pack →

JSON

12

Well specified, but the gaps fail silently. Duplicate keys, integers past the safe range and lone surrogates all parse without error and give you the wrong value.

Open pack →

XML

13

Well specified, but parsers are too accommodating. Entity expansion and external entity resolution are conformant features almost no application wants enabled.

Open pack →

YAML

13

The syntax rarely breaks; the types do. Unquoted NO becomes false, 22:22 becomes 1342, and 0755 becomes 493 — depending on which spec version your library implements.

Open pack →

XLSX

13

A ZIP archive of XML parts, so it inherits the failure modes of both — arriving in a file type applications treat as structured data rather than untrusted markup.

Open pack →

ZIP

11

Every header field is attacker-controlled. Entry paths, declared sizes and checksums are all promises the archive makes and extraction code routinely trusts.

Open pack →

How it works

  1. Pick a failure. Each pack groups its fixtures by category and severity. Every one explains what it tests and what a correct parser should do.
  2. Inspect the bytes. 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. The hex viewer highlights the bytes that matter and explains each one.
  3. Run it through your importer. Download one file, or take the whole pack as a ZIP with a README describing every entry.
  4. Record what survived. Mark each fixture passed or failed. Results are kept in your browser, so leaving the page to test is expected.
  5. Export the damage report. Copy a Markdown summary of what failed, with remediation for each, straight into a pull request.

Is this safe to download?

Yes. These are inert test files for checking your own import pipeline. Nothing executes on its own. The fixtures that model injection or path traversal exist so you can verify your code rejects them, and the resource-exhaustion ones are deliberately scaled down — the entity expansion fixture uses four nesting levels rather than the classic nine, so it demonstrates the behaviour without taking down the machine you are testing from.

Everything is generated in your browser. Nothing is uploaded, and there is no signup.