"The file is damaged and could not be repaired"

A PDF is not a top-to-bottom stream. It begins with a header like %PDF-1.7, then a body of numbered objects (each written as N 0 obj … endobj) holding the pages, fonts, images and content. After the body comes the cross-reference table (xref): a list of the exact byte offset of every object. Then a trailer names the document root and, crucially, the file ends with startxref followed by a byte offset and the %%EOF marker.

To open the file, a reader seeks to the end, reads startxref to learn where the xref lives, jumps there, and uses the offsets to find the root and load the pages. Everything hinges on that trailer being intact and the offsets being correct. PDF 1.5 and later can also store this map as a compressed cross-reference stream, and pack many objects into object streams (ObjStm) — more efficient, but it means one damaged stream at the tail can hide a great many objects at once.

Because the index and trailer sit at the very end, they are the first casualties when a save is interrupted, a download is truncated, or an incremental update is written badly. That is why "damaged" PDFs so often have perfectly good page content and a broken map to it.

Acrobat normally rebuilds a broken xref silently: if the offsets don't add up, it scans the file for obj markers and reconstructs the table without ever telling you. So "could not be repaired" means that fallback also failed — the damage went past what Acrobat's rebuilder will tolerate. The common reasons:

The tail was truncated. A download or copy that stopped early loses the xref, trailer, startxref and %%EOF outright, and possibly the last objects too. A bad incremental update. PDFs are often edited by appending a new xref section and trailer; if that append is corrupt, the chain of updates points to the wrong place. A damaged cross-reference or object stream. When the map itself is a compressed stream and that stream is corrupt, Acrobat can lose sight of the objects packed inside it. Byte mangling in transit — a text-mode transfer that altered line endings, or a sync that flipped bytes — can also scramble the offsets so nothing lines up.

In each case the useful insight is the same: the objects that make up your pages are frequently still present in the body; it is the directory to them that is broken.

Rather than trust the broken trailer, the tool scans the whole file for obj definitions, records where each one actually starts, and rebuilds the cross-reference table from those real positions. It then relinks the document root and page tree so a reader can walk the pages again, salvaging content streams, embedded fonts and images along the way. Where the map lived in a compressed cross-reference or object stream that survived, it reads those too; where the tail was truncated, it recovers every object that was written before the cut and assembles a valid PDF around them. This runs entirely in your browser tab — no Acrobat, no add-in, no server round-trip.

The honest limits: content that was never written can't be restored, so if the file was truncated, pages that hadn't been saved yet are gone — you get the pages up to the cut. If a specific object your pages depend on landed in the damaged region, that page may come back partial. And an encrypted, password-protected PDF can't be rebuilt without the password, because its objects are unreadable until decrypted. What the repair guarantees is privacy: contracts, medical records, statements and unpublished work are read from disk and reassembled locally, and you can watch the Network tab and confirm 0 bytes of the document ever leave your machine.