One click, and qpdf rebuilds what it can — inside your browser, far from any server
| Damage | Typical cause | Outcome |
|---|---|---|
| Zeroed or scrambled cross-reference table | Crash mid-save, disk fault | Full recovery — table rebuilt from objects |
| Wrong startxref pointer | Editor wrote bad offsets | Full recovery |
| Missing %%EOF / startxref tail | Truncated final write | Full recovery |
| Broken header line (not %PDF-) | Email/base64 mangling | Full recovery — header rescanned |
| Junk bytes before the %PDF header | Mail transport, concatenation | Full recovery |
| File truncated mid-content | Interrupted download | Partial — every complete page kept, partial page lost |
| Random bytes / empty file / header-only stub | Overwrite, zero-length save | Rejected — nothing left to recover |
| Encrypted, password unknown | Password lost | No tool can help — AES has no backdoor |
Every row was produced by actually breaking files and running this exact engine on them, not by reading a vendor's marketing. The truncation row is the one to internalize: repair salvages what's physically present, and a page cut off mid-download was never fully on your disk.
A PDF is a map plus territory. The territory — pages, fonts, images — is usually fine even in a file that won't open. The map is the cross-reference table: a list of byte offsets telling readers where every object lives. Damage the map and every reader, from Acrobat to your browser, refuses the whole file. Repair is map-making: walk the bytes, find objects by their structure, rebuild the table, write a clean file.
This tool runs qpdf compiled to WebAssembly — the same battle-tested structural engine that's been fixing PDFs since 2001, executing locally in your browser tab. qpdf's recovery mode scans for objects regardless of what the xref table claims, reconstructs what it finds, and refuses to emit a file when nothing recognizable remains (a random-byte file fails with "unable to find trailer dictionary," which is the honest answer rather than a fake success). First use downloads ~2.2 MB of WebAssembly; after that the browser caches it and the tool works offline.
Take a 40-page quarterly report, 19,749 bytes, and simulate the classic interrupted download by cutting it at 85% — 16,786 bytes remain, and the xref table plus trailer, which live at the end, are gone entirely. Repair rescans the byte stream, finds every complete page object, rebuilds the cross-reference table, and emits a valid 16,133-byte PDF with 35 of the 40 pages. The last five pages were cut mid-stream and simply aren't in the surviving bytes — no engine can restore what was never written. Now the gentler case: a 3-page report whose xref table gets scrambled (59 bytes of pointer data clobbered) keeps all its page content, so repair rebuilds the table and returns all 3 pages in a 1,654-byte file. Broken map, intact territory: full recovery. Truncated territory: salvage what's complete, lose what isn't.
Run it through a PDF repair tool built on a structural engine such as qpdf: it scans the raw bytes for objects, rebuilds the cross-reference table, and writes a fresh, valid file from everything it finds. Most "PDF won't open" errors are a damaged xref table or a truncated tail — both repair cleanly. Recovery is limited to pages whose bytes still exist; a file cut off mid-transfer gives back every complete page and loses the partial one.
The usual suspects: a transfer or download interrupted before the end (truncation), a write interrupted by a crash or full disk, an email or storage system that mangled the header bytes, and editors that exited mid-save. PDFs are fragile in a specific way — every object's location is written into a cross-reference table, and one bad offset makes readers give up on the whole file even when the pages themselves are intact.
Repairable: zeroed or scrambled xref tables, wrong startxref pointers, missing %%EOF trailers, damaged headers, junk bytes prepended before %PDF, and truncated files (complete pages are salvaged). Not repairable: files reduced to random bytes with no objects left, empty files, header-only stubs, and content that was never saved — if the bytes are gone, no tool can conjure them back. The engine rejects those outright rather than emitting a broken "repaired" file.
Probably not, and it's worth knowing why. Repair fixes structure — tables and pointers — so a reader can find every object. Blank pages are usually a rendering problem: missing or unusual fonts, transparency effects an old viewer can't draw, or scans stored in an unsupported image format. The page structure is fine; the pixels aren't. Try a different viewer first (or an update), because that fixes blank pages far more often than a repair does.
If you know the password, yes — type it in the password field and the engine decrypts while it repairs. If you don't know the password, no honest tool recovers the content: modern PDF encryption (AES) has no backdoor, and "password removal" services only work on files whose password you already have or that were secured with an empty one.
No. The repair engine is qpdf compiled to WebAssembly, running inside this page — a damaged contract or medical record never leaves your machine, and the tool keeps working offline once the engine has loaded. That matters here more than usual, because the files people bring to repair tools tend to be the ones they can't risk handing around.