Repair a damaged PDF

The word "repair" is the most over-promised term in the PDF business. A great many tools offering it do one thing: open the file with a tolerant library, save it again, and report success. Given a healthy file they change nothing and take credit; given a genuinely broken one they fail in the same way the reader already did.

This tool was rejected once for that reason, and built only after measuring what is actually recoverable. That measurement produced one finding worth repeating, because it contradicts the entire category.

**The classic corrupt PDF is not broken any more.** A cross-reference table pointing at the wrong offsets is the textbook damage, and every modern reader — including the two engines this site runs on, and the viewer built into your browser — reconstructs it by scanning the file for objects. Nothing needs repairing; it already works. So when this tool is given such a file, it says the document needs nothing rather than re-saving it and calling that a fix.

What is genuinely broken is a file with **content missing**. A download that stopped, a transfer that corrupted a block, a copy off failing storage. These parse to fewer pages than the document says it has, and that mismatch is why every other tool on this site refuses them — a check that is exactly right everywhere else, because processing twenty-three pages of a document someone believes has twenty-four is how content disappears without anyone noticing.

Repair is the one place that mismatch is the point. Measured on a twenty-four page document: truncated at ninety-five percent, twenty-three pages recover; at eighty percent, nineteen; at half, twelve. In every case the file was completely unopenable before and a working document after — and in every case you are told how many pages are gone, because a recovered file that quietly presents itself as complete is worse than no recovery at all.

There is a limitation worth understanding before you try, because it decides whether you get everything or nothing. Many PDF producers pack the document's objects into a few compressed streams. That is very good for file size, and it means partial damage is total damage: truncating any part of a compressed block destroys every object inside it, and there is no partial structure left to walk. A document written with plain objects degrades page by page. One written with object streams tends to go straight from working to unrecoverable.

Where the structure cannot be read at all, there is a last resort that is deliberately off by default. The renderer is considerably more tolerant than any writer, and can often still draw pages that no library will parse. Those pages can be captured as images and assembled into a new document — which gives you something readable and destroys everything that made it a document: no selectable text, no links, no forms, no bookmarks. It is offered when nothing else works, described as what it is, and never applied without being asked for.

All of it runs on your device. That matters more here than on most of these pages, because a damaged file is very often the only copy of something that is left.