Few document problems are as confusing as a PDF that opens perfectly on your phone and then fails everywhere it matters: the submission portal rejects it, the office printer refuses it, a colleague's reader reports it as damaged. Your first instinct is to blame the portal or the printer. Often, though, the file itself is the problem — damaged in a way that forgiving readers quietly work around and strict readers honestly refuse.
The usual culprit is the PDF's cross-reference table. Think of it as the index at the back of a book: it tells a reader where each part of the file lives, so the reader can jump straight to a page instead of scanning the whole file. If that index is broken — entries pointing at the wrong places, entries missing, the index itself truncated — a reader has two choices. A lenient reader can ignore the index, scan the file from start to finish, and reconstruct the document well enough to display it. A strict reader refuses to guess, because guessing wrong could show the wrong page or the wrong content. Both readers are behaving reasonably. The strict one is not being difficult; it is refusing to present a document it cannot verify.
Repair PDF addresses exactly this kind of structural damage. It re-reads the file's objects, rebuilds a clean cross-reference table, carries the metadata across, and reports the pages it found. It works in your browser, so the damaged file is not uploaded anywhere. But before you repair anything, it helps to understand what kind of damage you are dealing with, because repair has honest limits that shape what you should do next.
How a cross-reference breaks
A PDF is not a single stream of text. It is a collection of objects — pages, fonts, images, content streams — plus the index that locates them. That structure is robust in normal use, but it is vulnerable at the moments when a file is written or copied. An interrupted download is the most common cause: the file looks complete because the visible pages arrived, but the index at the end did not. A failed merge or a crashing editor can produce a similar result, writing the pages but not the index that ties them together. A failing drive or a corrupted transfer can damage the index while leaving most page content intact, which is why the file sometimes opens in one place and not another.
There is also a subtler cause: a file that was never quite valid, produced by software that wrote a sloppy index, and tolerated for years by lenient readers. It only becomes a problem when it meets a strict reader — a print shop's preflight check, a government portal, an archival system — that checks the structure properly. In that case the file did not suddenly break. It was always broken, and you have only just met a reader that says so.
Reading the symptoms
The error messages give clues, though they are rarely precise. "File is damaged" or "cannot be opened" usually means the reader could not trust the structure at all. A file that opens but shows blank pages, missing images, or garbled text may have damage beyond the index: some objects themselves are gone or unreadable, and no rebuilt index can restore them. A file that opens in a browser viewer but fails in a desktop reader is the classic cross-reference case, because browser viewers tend to be lenient and desktop readers stricter — but that is a tendency, not a rule, and you should not rely on which app opened it as proof of anything.
The most useful test is simple: try the file in two or three different readers, and note exactly what each one does. Does it refuse outright, or does it open with pages missing? Does the page count look right? Can you search the text? Those observations tell you whether you are likely dealing with index damage, which repair can fix, or content damage, which it cannot. Keep a copy of the damaged file untouched while you test, so that repair attempts never become your only copy.
What repair actually does
Repair does not wave a wand over a file. It reads through the objects it can find, works out where they actually are, and writes a new file with a correct index pointing at them. Metadata — the title, author, and similar information stored with the file — is carried across where it can be read. The result is a structurally clean file that strict readers can accept, built from the content that survived.
That description contains the key limit. Repair rebuilds structure; it cannot recover content that is genuinely gone. If a page's content stream was truncated in a bad download, the rebuilt file will either omit that page or show it damaged, and no repair step can invent the missing text. This is why a repaired file must be checked page by page afterwards, comparing it against what you expect the document to contain. A successful repair message means the structure is clean. It does not mean the document is complete.
If the repaired file is missing pages, your next step is not to repair it again. It is to find another copy: the original source, an email attachment, a backup, a colleague's copy. Repair is a recovery step for the copy you have, not a substitute for a source copy. The guide to merging and splitting PDFs covers how documents are commonly assembled, which is useful background when a merged file turns out to be the damaged one.
A fictional example: the portal rejection
Imagine a fictional applicant, Lena Fischer, submitting a fictional ten-page application pack to a fictional housing portal at example.org. The pack opens fine in her phone's viewer, so she uploads it. The portal rejects it as damaged. She tries it in a desktop reader, which also refuses it, and she now has two different behaviours from two readers — the classic sign of index damage.
Lena keeps the damaged file aside and runs a repair on a copy. The repaired file opens in the desktop reader, and the repair report lists ten pages. Lena does not stop there. She pages through all ten, checking that each page shows its expected content: the cover, the application form pages, the supporting letters. Page seven, a scanned letter, shows correctly. The page count matches, the text searches correctly, and only then does she upload the repaired file, which the portal accepts.
Had the repair reported nine pages, Lena's job would have changed. She would have known a page was lost, and her next step would have been to re-scan or re-request that page, not to submit a nine-page pack and hope nobody noticed. That distinction — structure fixed versus content complete — is the whole reason for the page-by-page check.
If the repaired pack later needs trimming, Remove Pages handles whole-page deletions, and Compare PDF can help check a repaired version against another copy, where one exists.
Honest limitations
Repair PDF cannot recover every damaged file. Some corruption is unrecoverable: content that was never written, or that was overwritten, is gone, and a rebuilt index cannot bring it back. A repaired file must be checked page by page against your expectations, because a clean structure does not prove complete content. Repair also cannot fix a file whose problem is not structural — a PDF that opens fine but contains the wrong text, a scanned image with no text layer, or a password-protected file you cannot unlock are different problems with different tools. Finally, repair works on the copy you give it; always keep the damaged original untouched until the repaired result has been verified, in case a second attempt or a different approach is needed.
FAQs
Why does my PDF say it is damaged?
Usually because its internal structure — most often the cross-reference table that locates each part of the file — is broken or incomplete. Lenient readers may work around the damage, while strict readers refuse the file, which is why the same file behaves differently in different apps.
What is a cross-reference table?
It is the index inside a PDF that tells a reader where each object — each page, font, and image — is stored in the file. Without a trustworthy index, a reader must either scan the whole file and guess, or refuse to open it.
Can a damaged PDF be repaired without the original file?
Sometimes, yes, if the damage is structural and the page content itself survived. Repair rebuilds the structure from the objects it can still read. If the content itself is gone, no repair can restore it, and you need another copy from the source.
Why does a PDF open in one app but fail in another?
Because readers differ in how strictly they check a file's structure. A lenient reader may ignore a broken index and reconstruct the document; a strict reader refuses to guess. The file is the same in both cases — the readers simply have different tolerances.
human review pending client designation