A download gets interrupted halfway through. Someone emails a PDF as an attachment and the transfer drops a few packets. A phone or laptop loses power while a scanning app is still writing the file to disk. An export from some niche accounting or CAD tool finishes “successfully” but writes a file that’s technically malformed. None of these are exotic failures — they’re ordinary interruptions — but the result is the same: a PDF that won’t open, or opens into an error.

What that looks like varies. Sometimes it’s a flat refusal — Acrobat pops up “There was an error opening this document. The file is damaged and could not be repaired,” and that’s the whole interaction. Sometimes it’s worse in a quieter way: the file opens, but page 14 is blank, or the text renders as garbage characters, or the viewer hangs on a spinner and never finishes loading. All of these usually trace back to the same category of problem — not the content itself being wrong, but the file’s internal bookkeeping being wrong.

What actually breaks inside a PDF

A PDF isn’t stored as a clean, linear “page 1, page 2, page 3.” Internally it’s a collection of objects — text streams, fonts, images, page definitions — plus a cross-reference table (the xref table) that tells a viewer the exact byte offset of every object in the file. A PDF reader doesn’t scan the whole file top to bottom looking for content; it jumps straight to the offsets the xref table gives it.

That table is small, and it’s usually one of the last things written when a PDF is saved. Which means it’s also one of the most common casualties of an interrupted write: a download that dies at 95%, a save that gets cut off by a crash, a transfer that drops the last chunk — any of these can leave the file’s actual page content intact while the index pointing to it is truncated, offset-wrong, or missing outright. A reader that goes looking for object offsets it’s been given and finds garbage, or finds nothing, gives up rather than guess.

What repairing a PDF actually does

Repair PDF doesn’t try to visually “clean up” a document or guess at what’s missing. It takes the file through up to three independent parsers, in this order:

  1. qpdf, first. The file is handed to qpdf — an open-source PDF engine, compiled to WebAssembly so it runs in your browser tab rather than on a server — for a plain read-then-rewrite pass. qpdf’s parser is deliberately tolerant of common structural damage: it can work around a broken or missing xref table by scanning the file for the objects it can find, then writes out a fresh, correctly-structured file from what it recovered. Just re-serializing the file this way fixes a large share of “won’t open” cases, because the underlying content was fine all along and only the index pointing to it was broken.
  2. pdf-lib, as a fallback. If qpdf can’t make sense of the file at all, it falls back to pdf-lib’s more lenient loading mode, which skips objects it can’t parse instead of throwing on them, and rebuilds the document from whatever it could read.
  3. pdfjs-dist, to verify. Whichever of the two produced an output, that result gets opened again with pdfjs-dist — a third, independent parser, unrelated to either of the first two — purely to confirm the repaired file actually opens. A “successful” repair that still doesn’t open in a real PDF reader isn’t a repair, so if that verification step fails, the tool reports the file couldn’t be fixed rather than handing you something that looks done but still isn’t readable.

What it can fix, and what it honestly can’t

This is worth being precise about, because “repair” can sound like it means “recover anything.” It doesn’t.

What it can fix is structural and format damage: a broken or missing xref table, object references that point to the wrong offset, a file that was truncated but still has most of its content intact, and the kind of malformed-but-mostly-there structure that a buggy export tool or an interrupted write commonly produces. In those cases, the actual page content, text, and images were written to the file correctly — only the map to them was damaged — and re-parsing and re-serializing recovers the whole thing.

What it can’t fix is data that was never written in the first place. If a transfer died early enough that entire pages’ worth of content bytes never made it into the file, or a scanning app crashed before it finished writing a page’s image data, that content is genuinely gone — not hidden behind a broken index, just absent. No parser, however tolerant, can reconstruct bytes that don’t exist anywhere in the file. In that situation, repair will typically still get you a file that opens, recovering everything that was actually saved, but it will not have pages or content that were never written. If the file fails verification even after both qpdf and pdf-lib have tried, that’s usually a sign the damage is more than structural — worth going back to whoever sent it, or the original export, for a clean copy.

It’s also not the same problem as a PDF that opens fine but loads slowly on the web — that’s a byte-ordering issue, not corruption, and Optimize PDF for Web is the tool for that instead.

Is it actually corrupted, or something else?

A few things get mistaken for corruption but aren’t, and it’s worth ruling them out first so you’re not running a repair on a file that was never broken in the first place.

  • A password prompt isn’t corruption. If the file asks you to type a password before it’ll open anything at all, it’s working exactly as designed — encryption is deliberately supposed to stop a reader from parsing the content without the key. Repair PDF won’t do anything for a file like this, because there’s nothing structurally wrong with it. If you know the password and just want it gone, Unlock PDF is the tool for that; if you don’t know it, no repair tool — this one included — can get you in without it.
  • Check the file size before you do anything else. If the PDF is 0 KB, or a few KB when it should be several megabytes, there’s no document in there to recover — the transfer or save died before any real content was written. A repair tool can only reconstruct the map to data that actually exists in the file; it can’t produce pages from a file that’s mostly empty.
  • Try opening it in one other viewer first. Occasionally a file is valid but written in a way one particular app is unusually strict about, and a second viewer opens it without complaint. That’s not corruption at all. If two or three different readers all fail on the same file the same way, that’s a real structural problem, and repair is worth trying.

Who this is for

  • A PDF that won’t open at all — Acrobat, Preview, or a browser reports it as damaged, invalid, or unreadable.
  • A file that opens with visible problems — missing pages, blank sections where content should be, or garbled text, after an interrupted download or a flaky transfer.
  • Attachments that arrived broken — an email client or upload form that clipped or partially transferred the file.
  • Output from a buggy export or scan — a report generator, accounting tool, or scanning app that wrote a technically malformed file even though it reported success.
  • Files off failing storage — a PDF pulled from a USB drive, SD card, or disk with read errors, where the copy itself may be incomplete.

Nothing leaves your device

qpdf, pdf-lib, and pdfjs-dist all run as WebAssembly or JavaScript inside your browser tab — the file is read, repaired, and verified locally, and none of it is uploaded to a server. That matters generally, but it matters more here specifically: a damaged file is often a damaged copy of something sensitive — a contract, a signed agreement, a scanned ID — and repairing it shouldn’t mean handing it to a third party first just to find out if it can be fixed.

Avoiding this next time

None of this is complicated, but it’s the same handful of habits that would have prevented most of the files that end up here:

  • Don’t trust a “download complete” message on its own for anything large or important on a flaky connection — if the sender can tell you the expected file size, compare it before you assume the transfer actually finished.
  • If you’re saving to a USB drive, SD card, or network share, wait for the write to actually finish and eject it properly before pulling it. The exact same interrupted-write problem that breaks a download breaks a save to removable media just as easily, and it’s a more common cause than it should be.
  • Keep a second copy of anything you can’t afford to lose — a signed contract, a scanned ID, a filed tax form — before you run it through any editor, converter, or merge tool. Corruption introduced during editing is rarer than corruption in transit, but it does happen, and a spare copy costs nothing.
  • If you’re regularly exporting from a tool that’s produced a malformed file before — a particular accounting package, a CAD export, a niche scanning app — get in the habit of reopening what it just wrote before you file it away or send it on. Catching a bad export immediately, while the source data is still there to re-export, is far easier than catching it weeks later when the original is long gone.