How to repair a pdf broken by a failed download
- Step 1Try a fresh download first — If the source URL still works, re-download on a stable connection — a complete file beats any recovery and gives you 100% of the pages. Use repair only when the source is gone, expired, or otherwise unreachable.
- Step 2Find the partial download and rename it — Look in your downloads folder for a
.crdownload(Chrome) or.part(Firefox) file. Right-click → Rename and change the extension to.pdf. If you don't see the extension, enable 'File name extensions' in Windows Explorer's View menu first. - Step 3Open the PDF Repair tool — Go to the PDF Repair tool. It rebuilds the file in your browser — no upload.
- Step 4Drop the renamed partial file in — Add the
.pdffile. Repair has no options and starts automatically. Only real PDFs are accepted, so the rename to.pdfis what lets the tool take the file. - Step 5Download the rebuilt PDF — pdf-lib copies the pages that finished downloading into a fresh document with a proper trailer and
%%EOF, then saves. Download the output. - Step 6Compare against the expected page count — Open the output and compare its page count to the full document. The shortfall is what hadn't downloaded yet when the connection failed — those bytes are only available from a complete download.
How much of a partial download you can expect back
Recovery tracks how far the download got, because PDFs are written front-to-back. These are rules of thumb — the exact result depends on where in the file the completed pages sit.
| How complete the download was | Typical recovery | Why |
|---|---|---|
| Nearly complete (only the tail missing) | All or almost all pages | Only the trailer/xref were cut; every page object downloaded |
| Mostly complete (cut late in the file) | Most pages | Most page objects finished; the last few never arrived |
| Roughly half downloaded | About the first half of pages | Pages download in order; the back half wasn't received |
| Only the start downloaded | A few early pages — or none | Too little arrived for complete page objects to resolve |
Partial-download file extensions and what to do
Browsers mark in-progress downloads with their own extensions. The tool only accepts real PDFs, so rename first.
| Extension | Source | Action before repair |
|---|---|---|
.crdownload | Chrome / Edge in-progress download | Rename to .pdf, then drop into the tool |
.part | Firefox in-progress download | Rename to .pdf, then drop into the tool |
.download | Safari in-progress download | Rename to .pdf, then drop into the tool |
.pdf (won't open) | Download finished 'successfully' but was cut by the server | Drop in directly — repair recovers what downloaded |
Cookbook
Real interrupted-download scenarios and what the rebuild recovers. The recovered page count maps directly to how far the download got.
Wi-Fi dropped near the end of a long PDF
A 40-page report was 95% downloaded when the connection died, leaving a .crdownload file. Almost every page finished; only the trailer and last couple of pages were missing.
Renamed report.crdownload -> report.pdf Repair (pdf-lib reload -> copyPages -> save): 38 page objects resolved and copied wrote fresh trailer + %%EOF Output: valid 38-page PDF (original 40 -> 2 pages short). Get the last 2 from a complete download if needed.
Server timeout cut the file at the tail only
The download 'finished' but the server closed the connection right after the last page, before the trailer. Every page is present; only the tail was lost.
file.pdf won't open: "unexpected end of file" Repair: all 12 page objects resolved and copied new trailer/xref written Output: complete 12-page PDF -- nothing lost, just the missing tail rebuilt.
Browser crash at roughly the halfway mark
The browser crashed about halfway through a 30-page download. Pages download in order, so the first half is recoverable and the second half never arrived.
Expected pages: 30 Recovered: 16 -> the crash hit ~halfway; pages 17-30 weren't downloaded. Re-download for the full set; merge with the recovered half via PDF Merge if you can only get the rest separately.
Half-written final page object
The connection dropped mid-way through writing the last page. pdf-lib skips the incomplete object and keeps the complete pages before it.
Repair: pdf-lib skips 1 incomplete trailing object copies the 9 complete pages before it Output: 9-page valid PDF. The partial 10th page can't be reconstructed.
Re-download wins when the source is still live
The partial file recovers most pages, but the original link still works — the right move is a clean re-download, not recovery.
Partial file: 22 of 28 pages recoverable Source link: still live Best action: re-download on a stable connection -> 28 pages. Use repair only if the link is dead or expired.
Edge cases and what actually happens
The back half of the document is missing
Partial recoveryAn interrupted download saves pages in order up to the point it failed — the later pages were never received and can't be recovered by any tool. The rebuild recovers everything that downloaded. Compare the recovered count to the full document; the shortfall is what hadn't arrived. A complete download is the only source for those pages.
Too little downloaded to parse
Parse failedIf the connection dropped before any complete page object was received, pdf-lib can't resolve anything and the load throws; the tool reports the error. There simply isn't enough of the file to rebuild from. Re-download from the source.
The source is still available
By designRepair recovers only the bytes that downloaded, which is by definition incomplete. If the original link or source still works, re-download on a stable connection for 100% of the pages. Reserve repair for dead links, expired sessions, or one-time downloads you can't repeat.
You can't see the .crdownload / .part extension
ExpectedWindows hides file extensions by default, so you may only see the base name. Enable 'File name extensions' under Explorer's View menu, then rename the partial file to end in .pdf. The tool accepts only real PDFs, so the .pdf extension is required before you can add it.
Bookmarks, form fields, or metadata are gone
Not preservedThese document-catalog features are usually written near the end of a PDF, so an interrupted download often never received them — and a rebuild wouldn't carry them anyway. Page content and page-level annotations are preserved. Re-add the rest if needed.
A digital signature is invalid after repair
Signature invalidatedA partial download already broke any signature (the signed byte range can't reach end-of-file), and a rebuild writes new bytes on top. If you need a signed copy, get the complete original and re-sign with PDF Sign, or verify the complete file with the PDF Signature Verifier.
Recovered file has empty metadata
By designThe rebuild saves with updateMetadata: false, producing a fresh empty metadata block; an interrupted download likely never received the original metadata anyway. Re-add title/author in your reader if your workflow needs it.
Partial file exceeds your tier limit
Limit reachedLimits apply to the input: free tier allows up to 2 MB and 50 pages. A partial download is smaller than the full file, but a large document's partial can still exceed the free cap — upgrade to Pro (50 MB / 500 pages) or Pro + Media (500 MB / 2,000 pages) if needed.
The download was of an encrypted PDF
LimitedignoreEncryption: true ignores a stale marker but doesn't decrypt real content, and an interrupted download often damages the encryption structures. For a genuinely encrypted document, a complete re-download is the reliable path; if you obtain a complete encrypted copy, decrypt it with PDF Unlock using the password.
You need to recover more than pdf-lib can parse
Out of scopeThis tool rebuilds via pdf-lib and won't carve raw bytes from a fragment pdf-lib can't parse. A desktop utility (qpdf --recover, Ghostscript, Mutool) may extract more from a very small partial download. Try this tool first — it instantly recovers the common case where most pages finished downloading.
Frequently asked questions
Why won't my interrupted download open?
Because the download stopped before the end of the file, and a PDF's trailer and cross-reference table — the parts a reader needs to locate the objects — live at the very end. The pages that finished downloading are usually intact, but without the tail no reader will open the file. A rebuild writes a new tail and recovers those pages.
How does the repair recover the pages?
It loads the partial file with pdf-lib's tolerant parser, copies every page object that finished downloading (and therefore resolves) into a brand-new document, and saves it with a freshly-written trailer, xref, and %%EOF. The output is a valid PDF of everything that downloaded — all in your browser, with no upload.
How do I rename a .crdownload or .part file to .pdf?
In Windows Explorer, right-click the file, choose Rename, and change the extension (.crdownload for Chrome/Edge, .part for Firefox, .download for Safari) to .pdf. If extensions are hidden, turn on 'File name extensions' under Explorer's View menu first. The tool accepts only real PDFs, so this rename is required.
How much of the file can typically be recovered?
It depends on how far the download got, because pages download front-to-back. A download cut off only at the tail recovers all or nearly all pages; one cut roughly halfway recovers about the first half; one that barely started may yield a few early pages or none. Compare the recovered count to the expected total to see exactly what arrived.
Should I repair or try a fresh download first?
Try a fresh download first whenever the source is still reachable — a complete file gives you 100% of the pages, while a recovered partial is always missing whatever hadn't downloaded. Use repair when re-downloading isn't possible: a dead link, an expired session, or a one-time download. It recovers what arrived, instantly and privately.
Is the partial file uploaded anywhere?
No. The rebuild runs entirely in your browser using pdf-lib and pdfjs-dist. The partial download never leaves your device. Only anonymous usage counters are recorded when you're signed in.
What if the repair produces nothing?
That means too little of the file downloaded for pdf-lib to resolve any complete page object, so the load throws and the tool reports the error. There isn't enough to rebuild from — re-download from the source. A desktop tool like qpdf (--recover) may extract fragments from a tiny partial file.
Does it matter which browser the download came from?
No. The tool reads the PDF bytes regardless of which browser or download manager produced the partial file. Chrome's .crdownload, Firefox's .part, Safari's .download, or a .pdf the server cut short all work the same way once renamed to .pdf.
Are there any settings to configure?
No. Repair has no options — it starts automatically when you add the file and simply rebuilds the structure by copying the downloaded pages into a fresh PDF with a proper trailer. There's no page selection or quality setting, because the goal is to recover everything that arrived.
Why are bookmarks, form fields, or metadata missing from the recovered file?
They're document-catalog features written near the end of a PDF, so an interrupted download often never received them — and a rebuild doesn't carry catalog features regardless. Page content and page-level annotations are preserved. Re-add bookmarks or metadata in a desktop editor if needed.
How big a file can I repair?
Free tier handles up to 2 MB and 50 pages; Pro up to 50 MB and 500 pages; Pro + Media up to 500 MB and 2,000 pages. The size is checked on the partial input before the rebuild runs.
Could repairing the partial file make things worse?
No. The tool reads your partial input and writes a separate new output — the original partial file is never modified. If the rebuild can't help, you still have the partial to feed to a desktop salvage tool or to compare against a fresh re-download.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.