Home › Blog › Repair a broken PDF

How to Repair a Corrupted PDF File, and Know When It Is Beyond Saving

A PDF that throws "file is damaged" or opens to blank pages is usually not rotten, it is unfinished: the last chunk of bytes never arrived, or the cross-reference table that tells readers where every object lives got mangled in transit. Repair tools rebuild that index from the bytes that did arrive. What they cannot do is invent bytes that were never there, and knowing the difference saves an hour of retrying.

How a PDF breaks in the wild

A PDF is objects plus an index: pages, fonts, images and text live as numbered objects, and a cross-reference table at the end points to each one. Interrupt a download and the table is missing or truncated. Copy a file through a flaky drive and a few object streams tear. Export from a tired printer driver and the header lies about version or length. Each failure produces a different symptom: refuse to open, open with missing pages, open with grey boxes where images were.

Notice what survives in all three: most objects are intact on disk. The document is not shredded, it is disindexed. That is precisely the damage a repair pass knows how to heal.

What repair actually does

A repair pass reads the file linearly, ignores the broken index and rebuilds a fresh one by recognising object boundaries in the byte stream. Pages whose objects survived come back whole; the trailing metadata that never arrived is simply regenerated. In-browser repair adds a privacy property worth caring about: a damaged bank statement or medical report is rebuilt on your device, not uploaded to a stranger's server for the privilege of being fixed.

After the rebuild, treat the output as a new original: run a stats check to confirm page count and dimensions, scroll every page once, and only then delete the damaged copy. Repair is surgery; you verify before you celebrate.

The cases no tool can save

If the missing bytes belonged to page content itself, a half-arrived scan, an export killed mid-write, then those pages are gone from this file forever. Repair will hand you the pages that survived and skip the ghosts. Likewise a file encrypted with a user password you do not hold is not corrupted, it is locked, and repair will rightly refuse.

Before declaring loss, chase the source: re-download from the sender, re-export from the application that produced it, check the email attachment again, look in the scanner's outbound folder. Nine times in ten the intact original still exists somewhere upstream, and five minutes of digging beats any algorithm.

Repair rebuilds the index, not the bytes. Chase the source first, repair second.

A workflow that actually saves files

• Copy the damaged file aside; never repair in place over your only copy.
• Re-download or re-export from the source if any route exists.
• Run the repair on the copy, locally in the browser.
• Verify: page count, dimensions, a visual scroll of every page.
• Keep both files for a week; damaged originals occasionally yield more on a second pass.

The order matters because each step is cheaper than the next, and because verification catches the silent failure mode: a repair that "worked" but dropped page seven of nine.

Not getting corrupted again

Prevention is dull and effective: let downloads finish before opening them, eject drives properly, export from the source application rather than printing to PDF twice, and keep the original export next to any converted copy. For archives, a yearly open-every-file pass catches rot while the source application still exists to re-export.

And when a portal rejects your upload with a vague "invalid file" message, run the stats check before blaming the portal: truncated exports from phone scanners are the usual culprit, and a repair plus re-save frequently turns a rejection into an acceptance.