Corrupted PDF Sample — A File That Won't Open, On Purpose

truncated at 55% · xref and trailer gone · guaranteed unreadable · CC0

Every PDF tool has an error path, and almost nobody tests it with a realistic broken file. This sample is a valid 6-page document cut off at 55% of its bytes — exactly what an interrupted download, a full disk, or a dropped connection produces. The header says PDF; the ending, cross-reference table and trailer simply never arrive.

What kind of "corrupted" this is

Truncation — the most common real-world corruption. A PDF's table of contents (the xref table) and its trailer live at the end of the file, so a file cut anywhere loses the map to everything, even the parts that are present. Strict parsers give up immediately; forgiving ones (pdf.js among them) attempt a rescue by re-scanning the whole file for object markers — you'll see it log Indexing all PDF objects — and still fail here, because the objects themselves end mid-stream. That two-stage failure is realistic and worth observing in your own stack.

What to test with it

• Error message quality — feed it to any tool on this site, or yours. The user should see "this file appears damaged", not a stack trace, a spinner that never resolves, or a silent empty result.
• Upload validation — servers that sniff only the %PDF- magic bytes will accept this file happily; whatever processes it later inherits the explosion. Decide which layer should catch it, then verify that layer does.
• Batch resilience — put it in the middle of a merge queue between two good files: correct behavior is one per-file error and a completed batch, not a lost batch.
• Timeout behavior — rescue-scanning a broken file takes longer than parsing a good one; on a large corrupted file that can look like a hang. Watch what your UI shows during the attempt.
• Repair-tool honesty — anything claiming to "repair any PDF" meets its match here: the missing 45% of bytes doesn't exist to recover. A truthful repair tool reports partial or no recovery.

Can a truncated PDF be repaired?

Partially, sometimes. Objects that fully arrived before the cut — fonts, early page content — can be re-indexed by a rescue parser, which is how "PDF repair" tools work when they work. But pages whose content streams were cut are gone: bytes that never existed can't be reconstructed. The honest framing is salvage, not repair. If the file mattered, the better path is almost always re-downloading or re-exporting from the source.

FAQ