Repairing a damaged PDF: what can be saved and what can't

The file downloads, you double-click, and the viewer says "Failed to load PDF" — or worse, it opens a few pages and gives up. "Corrupted" covers very different failures, from a five-second fix to data that is genuinely gone. Knowing which one you have saves you from both pointless repair attempts and premature surrender.

Where a PDF actually breaks

A PDF is a sequence of objects — pages, fonts, images — plus a cross-reference table at the end that records where each object lives. The file starts with a %PDF header and ends with a startxref pointer and the %%EOF marker. Damage to the map or the tail is common and usually repairable; damage to the objects themselves is the serious kind. Where the bytes were lost determines almost everything about your odds.

The fixable kind: broken maps, truncated tails

The most common corruption — an interrupted download or a broken cross-reference table — destroys the index but leaves the content intact. Repair tools rebuild the map by scanning the file for object markers instead of trusting the broken table, skipping whatever they cannot parse. That is exactly what our Repair PDF tool does: it reports how many objects survived before you commit to anything. The honest caveat: a rebuilt file can lose interactive features like forms, annotations, and bookmarks even when every page comes back.

The unfixable kind: bytes that are no longer there

No tool can recover content that the file simply does not contain. If that sounds obvious, look at how many "recovery" products imply otherwise:

• A file overwritten by another one: the old content is gone from the disk; only backups help.
• Dead sectors or a dying drive: pages whose bytes were zeroed out are lost, and every read attempt can make a failing disk worse.
• Ransomware encryption: that is not structural corruption — without the key (or a backup), the file stays scrambled forever.
• Severe truncation: if the download stopped at page 3 of 40, no repair tool can invent pages 4 through 40.

A five-minute triage routine

Before assuming the worst, run through this order — cheapest fixes first:

• Try another viewer. Browsers are the strictest parsers; some desktop viewers quietly open files that browsers reject. If it opens anywhere, re-save it from there.
• Check the file size against the source. A file that stops at a suspiciously round number of kilobytes was probably truncated — re-download or re-export it.
• Go back to the source. The original on the sender's machine, in your email attachment history, or in cloud version history beats any repair.
• Run a repair tool and read the diagnosis. If it finds zero parseable objects, stop — you are in the unfixable category.
• Salvage what survived. Pull the readable text or the surviving pages first, then take stock of what is missing.

When partial is good enough

A repaired file missing pages 12 and 13 is still a win if you needed the other forty. Pull the readable text with a text extractor, export the surviving pages, and note the gaps before you forward the document to anyone. For scans where the images survived but the structure did not, OCR can rebuild a searchable text layer on top.

Prevention beats repair

Keep the source file of anything important — the .docx, the original scan, the export — because regenerating a PDF is always more reliable than repairing one. For documents you must keep for years, store a second copy somewhere else and consider PDF/A, the archival flavor of the format built for long-term survival. And verify large downloads by size before deleting the original: five seconds of checking beats an afternoon of salvage work.