When a PDF will not open, the temptation is to try everything at once: rename it, convert it, open it in five apps, email it to yourself. That flailing rarely helps, and it can hurt, because each attempt risks overwriting the only copy you have. A calmer sequence works better: protect the original, diagnose what kind of damage you face, repair a copy, and then verify the result before you rely on it. This post walks through that sequence with a fictional example, so you can follow it the next time a file refuses to open.
The tool at the centre of the walkthrough is Repair PDF, which rebuilds a PDF's broken cross-reference table in your browser. It re-reads the file's objects, writes a clean structure, carries metadata across where it can be read, and reports the pages it found. Nothing is uploaded. That browser-only handling matters here, because a damaged file is often also a sensitive one — a contract, an application, a medical form — and sending it to an unknown server to be fixed would be a second problem on top of the first.
Step one: protect the original
Before anything else, make a copy of the damaged file and put the original somewhere safe — a separate folder, a USB stick, whatever you have. Do all repair attempts on copies. This sounds overcautious until the day a repair attempt makes things worse, or a conversion tool overwrites your input, and the damaged original was still the best version you had. Damaged does not mean worthless: a file that one reader refuses may still contain nearly all its content, and a later approach may recover more from it than the first attempt did.
While you are at it, note what you know about the file. Where did it come from — a download, an email attachment, a scanner, a merge? When did it last open correctly? How many pages should it have, and what should be on the first and last pages? Those facts become your verification checklist later. Without them, you cannot tell a complete repair from a partial one, because you have nothing to compare the result against.
Step two: diagnose before you repair
Open the damaged copy in two different readers if you can, and write down what each one does. A file that opens in a lenient viewer but fails in a strict reader points at structural damage — the cross-reference problem repair is built for. A file that opens everywhere but shows blank or garbled pages points at content damage, which repair may not fix. A file that fails everywhere with the same message could be either, or could be truncated — missing its ending entirely, in which case the later pages are simply not in the file.
Also check the file size against your expectations. A ten-page report that should be several megabytes but is only a few kilobytes is almost certainly truncated, and repair cannot restore pages that were never downloaded. A file of plausible size with a structural complaint is a much better repair candidate. This two-minute diagnosis saves you from expecting repair to do something it cannot do, and from blaming the tool when the real problem is a missing download.
Step three: repair a copy
Now run the repair on a copy of the file, not the original. The repair reads the objects it can find and builds a new file with a correct index. Pay attention to the report it gives you, especially the page count. If the report says the repaired file has the number of pages you expected, that is encouraging. If it says fewer, that is information, not failure: it tells you which pages did not survive, and it tells you to go looking for another copy of those pages rather than submitting an incomplete document.
Do not repair the repaired file repeatedly in the hope that a second pass finds more. Repair works from the objects present in the input; running it again on its own output will not conjure objects that were absent the first time. If the first repair leaves gaps, the productive next step is a different source copy — the sender, the original system, a backup — not another pass over the same damaged bytes.
Worked example: a fictional contract pack
Take a fictional twelve-page contract pack prepared for a fictional small business owner, Marco Reyes, by a fictional solicitor's office at example.org. The pack was emailed as an attachment, and Marco's download was interrupted by a dropped connection. The file opens in his phone viewer, showing what looks like the whole pack, but his desktop reader refuses it and the firm's portal rejects it.
Marco follows the sequence. He saves the damaged file untouched in a folder called "original - do not edit" and works on a copy. His checklist says: twelve pages, opening with a cover letter, closing with a signature page, with a fee schedule on page eight. The desktop reader's refusal, combined with the phone viewer's success, points at structural damage, and the file size looks plausible for twelve pages, so repair is a reasonable next step.
The repair reports twelve pages. Marco does not upload it straight away. He opens the repaired file and checks it page by page against his checklist: cover letter present, fee schedule on page eight with the figures he expects, signature page last and complete. He also searches the text for a distinctive phrase from the middle of the pack, to confirm the text layer survived rather than just the page images. Only after that check does he upload the repaired file, which the portal accepts.
Suppose instead the repair had reported eleven pages, with the fee schedule missing. Marco's correct move would be to contact the solicitor's office for a fresh copy of that page, then rejoin it to the pack. Merge PDF could join the replacement page in the right position, and Organize PDF could confirm the order visually. Submitting an eleven-page contract pack and hoping the missing fee schedule goes unnoticed would be worse than the delay of asking for it.
For a repaired file that needs checking against another copy, the guide on comparing documents explains how to spot differences systematically rather than relying on memory.
Step four: verify, then trust
Verification deserves its own step because it is the step people skip. Open the repaired file in the reader or portal that originally rejected it, if you can — that is the only acceptance test that matters. Then page through it completely, not just the first and last pages. Check that images render, that text is selectable and searchable where it should be, and that no page is blank or half-rendered. Compare the page count with your checklist. If anything is off, treat the repair as partial and go back to finding a source copy for the missing material.
Once verified, keep both files for a while: the damaged original, in case a question arises later, and the repaired version as the working copy. Rename the repaired file clearly so nobody mistakes it for the original, and note in your records that it is a repaired copy. That note costs ten seconds and can save an awkward conversation months later about why two copies of the same document differ.
Honest limitations
Repair PDF cannot recover every damaged file. Some corruption is unrecoverable: if page content was truncated, overwritten, or never written, no rebuilt index can restore it. A repaired file must be checked page by page, because a clean structure is not proof of complete content — a file can repair successfully and still be missing a page, an image, or a section of text. Repair also cannot fix non-structural problems: wrong content, a missing text layer on a scan, or a password you do not have are separate issues. Finally, always work on copies and keep the damaged original until verification is complete, because a repair attempt is a transformation, and transformations should never destroy your only source.
FAQs
Why won't my PDF open?
The most common structural cause is a broken or incomplete cross-reference table, often after an interrupted download, a failed merge, or a corrupted transfer. Content damage — truncated or overwritten pages — is also possible, and the two kinds of damage call for different responses.
Can a damaged PDF be repaired without the original file?
If the damage is structural and the page content survived in the file, repair can rebuild the structure from what is there. If the content itself is gone, you need another copy from the source; repair cannot invent missing pages.
What should I check after repairing a PDF?
Check the page count against what you expect, page through every page, confirm images render and text is searchable where it should be, and test the file in the reader or portal that originally rejected it. Do not trust a repair report alone.
Should I repair the original file directly?
No. Always repair a copy and keep the damaged original untouched until the repaired result is verified. If the first attempt is partial, the original may still yield more through a different approach.
human review pending client designation