PDF Repair

Recover corrupted or broken PDFs with a three-stage repair engine — runs locally.

100% private

Attempt to repair a corrupted or damaged PDF — re-parse the file structure, recover readable pages, and rebuild a clean output document. The three-stage engine handles PDFs that throw errors in Reader, partially-downloaded files, and documents with broken object references. Success depends on how badly damaged the file is, but the repair runs entirely locally via pdf-lib — so even when a recovery fails, you have not sent a broken file containing potentially sensitive content to anyone.

Three-stage repair engine

1

Clean re-parse

Reads the PDF structure and, if it loads, writes a clean optimised copy. Invalid objects are skipped automatically.

2

Recovery retry

Retries the load with encryption errors bypassed, then rebuilds whatever structure could be read.

3

Page rendering

Last resort: renders each page to an image and rebuilds the PDF. Text selection is lost but the document is viewable.

Stage 3 note: If structural recovery fails, each page is rendered as a JPEG image — text will not be selectable in the output. Stages 1 & 2 always preserve text.

Next steps

PDF Compressor

Optimise the repaired PDF size

PDF Merger

Combine with other documents

PDF Password

Protect the recovered file

Edit metadata

View, edit, or strip hidden metadata — title, author, creator, timestamps — before sharing.

View all tools →
Runs right inside your browser tab. No uploads. Your files stay private.

How PDF Repair Works — Three-Stage Recovery from xref to Rasterization

PDF is a structured binary format: a header, a sequence of indirect objects, an xref table that records the byte offset of every object, and a trailer. When any of those parts are damaged — by a failed download, interrupted save, bit rot on archival media, or a corrupted USB transfer — most viewers refuse to open the file. PDF Repair attempts to rescue what is recoverable using a three-stage pipeline running without any file leaving your device.
Stage 1 loads the file with pdf-lib and, if it parses, writes a clean rewrite. Because the library re-serializes the whole document from the objects it can read, this succeeds on PDFs with minor formatting issues that stricter viewers reject — non-compliant headers, missing whitespace, slightly malformed xref entries — and produces a standards-compliant output that matches the original content.
Stage 2 is a recovery retry, also via pdf-lib. pdf-lib already skips individual invalid objects while parsing, so the key difference here is that Stage 2 loads the file with encryption errors ignored — useful when Stage 1 stopped because the file declared encryption it could not negotiate. Text, fonts, hyperlinks, and vector graphics survive when their underlying objects are intact, and the output is re-serialized into a clean structure.
Stage 3 is rasterization through pdfjs-dist. PDF.js is far more tolerant of corruption than pdf-lib because it was designed to render anything browsers might encounter. Each page that PDF.js can render is captured to a canvas, JPEG-encoded, and stitched into a fresh PDF using pdf-lib. This stage produces a viewable file even from heavily corrupted inputs but loses text selection, search, and copy-paste because every page becomes an image.
The pipeline runs stages in order and stops at the first that succeeds. If Stage 1 produces a usable file, Stages 2 and 3 are skipped. If all three fail, the engine reports which stage failed and why — usually because the file was truncated below a recoverable threshold or because the entire content stream was overwritten with zeros.
Realistic limits: PDFs that have been partially overwritten with garbage, encrypted with a key that is no longer available, or truncated to less than ~200 bytes are unrecoverable. Files damaged by bit-flips on a few bytes usually recover at Stage 1 or Stage 2. Files that crashed mid-save often recover at Stage 2 with the last few pages missing.
All three stages run in your browser — pdf-lib for parsing and rebuilding, pdfjs-dist (with its WebAssembly worker) for rendering. No file leaves your device. After repair, run the result through PDF Compressor if Stage 3 was used, since rasterized pages are much larger than the original text/vector content.

Common Use Cases

01

Recover a truncated download

A PDF cut off mid-download often has a corrupt trailer but mostly intact pages — Stage 2 typically recovers the readable portion.

02

Fix bit-rot on old archives

Backups on aging hard drives or optical media occasionally develop bit-flips that confuse strict parsers; lenient mode usually rebuilds them.

03

Salvage a partial save

When an application crashed mid-save, Stage 2 can recover content that was already written, often with only the final page or two missing.

04

Open non-compliant PDFs

Some PDFs from older or specialized generators don't pass strict spec validation. Stage 1 produces a clean, compliant copy that opens in every reader.

Frequently Asked Questions

No. Files where the content streams have been overwritten with zeros, where the file has been truncated below ~200 bytes, or where encryption keys are missing are unrecoverable. The engine reports which stage failed and why.
Yes if recovery succeeds at Stage 1 or Stage 2 — those preserve the original text, fonts, and hyperlinks. Stage 3 rasterizes each page to a JPEG, so text is no longer selectable in the output. Run the result through PDF OCR to restore searchability.
No. All three stages — pdf-lib parsing, lenient reconstruction, and pdfjs-dist rendering — run in-browser, with nothing transmitted. Files stay in tab memory and are never transmitted.
No — pdf-lib cannot decrypt protected PDFs, so encrypted content streams stay unreadable regardless of stage. Unlock the file first with the PDF Password tool, then run the unlocked copy through repair.
Stage 3 embeds every page as a JPEG image, which is far less compact than compressed PDF text and vector data. A 2 MB text PDF might balloon to 20–40 MB after Stage 3. Run the output through PDF Compressor to reduce size.
Stage 1 and Stage 2 preserve form fields, annotations, and hyperlinks if the underlying objects are intact. Stage 3 flattens everything into the page image, losing interactivity.
Many viewers have stricter validation than the actual PDF spec requires. Stage 1 uses pdf-lib's parser plus a clean re-serialization, which produces a standards-compliant copy even when the source had cosmetic non-compliance issues.
Stage 1 and 2 are near-instant for most files. Stage 3 takes proportional to page count — about half a second per page on a modern laptop. A 50-page rasterization run takes 25–30 seconds.
There is no fixed limit in code, but everything runs in your tab's memory. Small and mid-size PDFs repair quickly; very large or image-heavy files can be slow and may run out of memory during Stage 3, since each page is rendered to a full-resolution canvas before encoding. If a big file struggles, try splitting it first.
Stage 1 and 2 preserve embedded font subsets exactly. Stage 3 rasterizes pages, so the font rendering is captured as pixels — the result looks identical but no longer carries the embedded font data.
Maintained by the WebToolVerse teamLast updated Suggest an edit

Advertisement

What's next?
PDF Compressor
PDF Merger