Repair PDF

A PDF is a collection of numbered objects — pages, fonts, images, streams — plus a cross-reference table at the end recording the byte offset of each one. Viewers read that table first and then jump straight to whatever they need. It is an efficient design with one consequence: the index is written last, and a file whose index is missing or wrong is unreadable even though every object in it is perfectly intact.

That is why interrupted saves are the leading cause. A crash mid-write, a disk that fills up, a USB drive pulled out, a network share that drops, a download that ends early — all produce a file with good content and a bad map. Email systems that alter attachments in transit and failing storage account for most of the remainder.

The encouraging part is that in the common cases the data is still there. Recovery is a matter of scanning the file for the objects, working out what they are, and building a correct index around them, rather than reconstructing anything from nothing.

There is no single repair that is right for every file, so several are tried in order of increasing intervention and the first one that produces a genuinely working document is what you get.

The first pass rebuilds the cross-reference table and object structure, scanning the file for objects and reconstructing the index around them. It fixes the largest share of real-world damage and changes nothing about the pages themselves. If that is not enough, a full re-render interprets each page and writes it out again as a new document — heavier, and able to recover files whose page content is itself malformed, at the cost of re-encoding. A final structural rewrite handles the remaining cases where the document can be parsed but not saved correctly.

Every candidate is re-opened and validated before being offered. That matters more than it sounds: a repair that produces a plausible-looking file which fails when someone actually needs it is worse than an honest failure, so a file that cannot be verified is never returned.

Recoverable damage is damage to the map rather than the territory: broken cross-reference tables, corrupt object streams, incorrect offsets, a truncated tail, structural errors from software that wrote the file incorrectly. In these cases the pages usually all return.

Unrecoverable damage is missing data. A download that stopped at 30% does not contain the other 70%, and nothing can infer it. A file overwritten by another, a file whose bytes have been scrambled by a failing disk, or something that is not a PDF at all — all are beyond any repair tool, however sophisticated.

The honest way to think about it is that repair reorganises what survives. When a page's content stream is genuinely gone, that page cannot be rebuilt, and the report will tell you the count came back short rather than quietly handing you a document with a hole in it.

Work on a copy and keep the damaged original. Repair strategies are attempted against the file as given, and having the original means a different approach can be tried later if the first result is incomplete.

Spend two minutes looking for a better source first, because it beats any repair. Check the sender's mailbox, your cloud storage version history, the application that generated the file, and the recycle bin. A regenerated file is perfect; a repaired one is as good as what survived.

Once you have a working document, verify it properly — open every page rather than the first, confirm the page count, and check that text still selects. Then it behaves like any other PDF, so Compress PDF, Merge PDF and the rest all work on it normally.