"The file is damaged and could not be repaired." Every PDF user meets this message eventually, usually holding something important. The good news: most corrupt PDFs aren't dead — they're disorganized. The catch: knowing which kind you have, because one kind comes back whole and one kind comes back short.
A PDF is two things: the content itself (pages, fonts, images, stored as numbered objects) and a cross-reference table at the end of the file — essentially a map of byte offsets saying "object 12 lives at byte 4,481." Readers trust that map absolutely. That design makes PDFs fast to open and easy to append, but it concentrates the failure risk: truncate the file, corrupt the table, or write one bad offset, and readers reject the entire document even though every page is sitting there intact. The common causes all attack the map:
A repair engine does what the name of the file format suggests it might: it stops trusting the map and re-surveys the territory. qpdf's recovery mode scans the raw byte stream for object patterns — n 0 obj … endobj — regardless of what the broken table claims, rebuilds a correct cross-reference table from what it finds, and writes a fresh file. In testing on deliberately broken documents: a 3-page file with 59 bytes of its xref table scrambled repairs to a fully valid 3-page document (1,654 bytes out), because the content was all present. Bad header lines, wrong startxref pointers, missing %%EOF trailers, and junk prepended before the header — all full recoveries. This is the common case, and it's why "PDF repair" tools work as often as they do.
When the file is cut short, repair can only return what's physically there. The same engine run on a 40-page, 19,749-byte report cut at the 85% mark — exactly what an interrupted download produces — recovered 35 complete pages in a valid 16,133-byte file. The final five pages were never in the surviving bytes; no engine restores bytes that were never written. So the practical checklist for a truncated file: repair it, count the recovered pages against what you expected, and go back to the source (re-download, re-export, ask the sender) for the tail. And at the far end of the spectrum, a file reduced to random bytes, an empty file, or a bare header stub gets honestly rejected — "unable to find trailer dictionary" — because there's nothing to rebuild from. A tool that "repairs" those is lying to you.
| Symptom | Real problem | Repair helps? |
|---|---|---|
| "File is damaged" / won't open | Broken xref table or trailer | Yes — full recovery typical |
| Opens in preview, fails in Acrobat (or vice versa) | Partially invalid offsets; readers differ in strictness | Yes |
| Junk characters before %PDF in a text editor | Transport garbage prepended | Yes |
| File ends abruptly, smaller than expected | Truncated transfer | Partially — complete pages only |
| Opens fine, but pages render blank | Rendering: fonts, transparency, image codec | No — update or switch viewers |
| Asks for a password nobody knows | Encryption working as designed | No — AES has no backdoor |
Encryption and damage are separate problems that sometimes arrive together. If you know the password, a repair tool that accepts one will decrypt while it rebuilds. If you don't, no legitimate tool can help: modern PDF encryption is AES with keys derived from the password, and there is no master key. Services advertising password "removal" recover files that were encrypted with an empty user password — restrictions-only encryption — not files whose real password is lost. Keep the password with the archive; that's the whole recovery plan for encrypted PDFs.
The documents people bring to repair tools are the documents they can least afford to leak — signed contracts, medical records, financial statements. Uploading a damaged file to an unknown server to fix it trades one problem for a worse one. Browser-based repair changes the calculus: when the engine is WebAssembly running in the page (qpdf compiled to wasm, in our tool's case), the file never leaves the machine, and the giveaway is simple — the tool keeps working offline after it loads. That's the class of tool to prefer for anything sensitive.
Open the damaged file and hit Repair — qpdf-wasm rebuilds the cross-reference table locally, recovers every complete page, and never uploads anything.
Repair Corrupt PDF →Repair rebuilds maps, not territory. Broken table, bad offsets, missing trailer, mangled header — rebuildable, usually to a whole file. Truncated content — salvage the complete pages and re-fetch the rest. Blank pages — a viewer problem, not a repair job. Run the fix locally when the document is sensitive. Our Repair Corrupt PDF tool does exactly this in your browser; once your file is healthy again, Compress PDF can shrink it for sending and Merge PDF can reassemble it with other documents.