How to fix the 'unexpected end of file' error in a pdf
- Step 1Confirm the error points to truncation — Note the exact message: 'unexpected end of file', 'EOF marker not found', 'missing trailer', or 'the file is damaged'. These all indicate the file's tail (trailer + xref) is missing — the signature of a truncated file, which is the case this tool handles best.
- Step 2If you can, re-download or re-export first — A truncated file is missing real data. If the source is still reachable, a fresh complete download or a re-export from the original app gives you 100% of the content — always better than recovering a partial file. Use repair when that isn't possible.
- Step 3Open the PDF Repair tool — Go to the PDF Repair tool. It rebuilds the file in your browser — no upload.
- Step 4Drop the truncated PDF in — Add the
.pdffile. Repair has no options and starts automatically. Only real PDFs are accepted. - Step 5Download the rebuilt PDF — pdf-lib copies the resolvable pages into a fresh document with a proper trailer and
%%EOF, then saves. Download the output. - Step 6Check the page count against the original — Open the output and compare its page count to the full original. The difference is what the truncation cut off — those pages' bytes never arrived and can only come from a complete copy.
What 'unexpected end of file' means and what the rebuild does
The error is about the file's missing tail. The rebuild writes a new tail and recovers everything that arrived before the cut.
| Reader message | What's actually wrong | Rebuild outcome |
|---|---|---|
| 'Unexpected end of file' / 'EOF marker not found' | The %%EOF marker and trailer at the file's end are missing (truncated) | Recoverable — copy resolvable pages, write a fresh trailer/xref |
| 'Missing trailer' / 'cross-reference table not found' | The xref/trailer that index the objects didn't make it into the file | Recoverable — the rebuild generates a new xref from the copied pages |
| 'The file is damaged and could not be repaired' | Strict reader gives up on the truncated structure | Recoverable if pages before the cut resolve |
| Reader opens but shows fewer pages than expected | Truncation cut off later pages; earlier pages intact | Partial — recovers the earlier pages; later ones are gone |
| Reader can't parse anything | Cut landed mid-structure, no resolvable pages | Not recoverable — re-download/re-export required |
Repair vs. re-download — which to choose
Repair recovers what's in a truncated file; it can't bring back bytes that were never written to disk. Prefer a complete source when one exists.
| Situation | Best action | Why |
|---|---|---|
| Source is still reachable | Re-download or re-export | Gives you 100% of the content; a truncated file is always partial |
| Source is gone, file is the only copy | Repair (this tool) | Recovers all pages before the truncation point, instantly and privately |
| Need the missing tail pages specifically | Get a complete copy | Those pages' bytes aren't in the truncated file at all |
| File won't parse even partially | Re-download / desktop salvage | pdf-lib needs resolvable pages to rebuild |
Cookbook
Real truncation scenarios and what the rebuild recovers. The recovered page count tells you precisely where the file was cut.
Truncated export, trailer missing
A 'Save As PDF' was interrupted, so the file ends without a trailer and every reader throws 'unexpected end of file'. The page objects up to the cut are intact.
Before: Acrobat: "unexpected end of file" Chrome: "Failed to load PDF document" Repair (pdf-lib reload -> copyPages -> save): resolved 22 page objects before the cut, copied them wrote a fresh trailer + %%EOF After: valid 22-page PDF (original was 25 -> 3 pages lost)
Recovered all pages — only the tail was missing
The truncation removed only the trailer and xref, not any page data. Every page resolves and the rebuild loses nothing.
Original pages: 10 Recovered: 10 -> the cut removed only the file's tail (trailer/xref). All page bytes were present; nothing lost. Output: clean 10-page PDF that opens everywhere.
Partly-written final object near the cut
The last page object was only half-written when the file was truncated. pdf-lib skips the incomplete object and keeps the complete pages before it.
Repair: pdf-lib skips 1 incomplete trailing object copies the 14 complete pages before it Output: 14-page valid PDF. The partial 15th page can't be reconstructed -- get a complete copy if you need it.
Re-download beats repair when the source is live
The file is truncated but the URL still works. The right move is a fresh download — repair only when you can't get a complete file.
Truncated file: 18 of 26 pages recoverable Source URL: still live Best action: re-download on a stable connection -> 26 pages. Use repair only if the source is gone.
Cut too early to parse anything
The download died almost immediately, leaving a file with no complete page objects. pdf-lib can't parse it and the rebuild can't proceed.
Repair attempt: pdf-lib PDFDocument.load() throws -- no resolvable pages Nothing to recover. Re-download/re-export; a desktop tool like qpdf --recover may extract more from the fragment.
Edge cases and what actually happens
Pages after the truncation point are missing
Partial recoveryTruncation removes the end of the file, so the later pages' bytes were never saved — no tool can recover them. The rebuild recovers everything before the cut. Compare the recovered count to the full original; the difference is what the truncation removed. A complete copy is the only source for those pages.
The file was cut too early to parse
Parse failedIf the truncation landed before any complete page object was written, pdf-lib has nothing to resolve and the load throws; the tool reports the error. Re-download or re-export the source. A desktop tool such as qpdf (--recover) may sometimes extract fragments from a tiny partial file.
The source is still available
By designRepair recovers only what's in the truncated file, which is by definition incomplete. If the original URL or source app is still reachable, re-download or re-export to get 100% of the content. Use repair when a complete copy is genuinely unavailable.
It opens in one viewer but not another
ExpectedSome viewers (Chrome, Firefox) tolerate a missing trailer and show partial content, while strict readers (Acrobat) refuse. Don't rely on the lenient viewer's partial render — run repair to produce a formally valid file that opens correctly everywhere, with a real %%EOF and xref.
Bookmarks, form fields, or metadata are gone
Not preservedThese are document-catalog features, not page content, so a rebuild doesn't carry them — and a truncated file may have lost them anyway (they're often written near the end). Page content and page-level annotations are preserved. Rebuild or re-add the rest if needed.
A digital signature is invalid after repair
Signature invalidatedTruncation already broke any signature (the signed byte range no longer reaches end-of-file), and a rebuild writes new bytes on top of that. Re-sign the repaired file with PDF Sign if needed and verify with the PDF Signature Verifier.
Recovered file's metadata is empty
By designThe rebuild saves with updateMetadata: false, so the output has a fresh empty metadata block. With a truncated source the original metadata may not have survived anyway. Re-add title/author in your reader if required.
Truncated file is still over your tier limit
Limit reachedLimits apply to the input: free tier allows up to 2 MB and 50 pages. A truncated file is smaller than the original, but a large document can still exceed the free cap — upgrade to Pro (50 MB / 500 pages) or Pro + Media (500 MB / 2,000 pages) if so.
The original was encrypted
LimitedignoreEncryption: true lets the tool load past a stale marker, but it doesn't decrypt real content. If the truncated file is genuinely encrypted, you'd need the password and PDF Unlock — though truncation often damages encryption structures, making a complete re-download the more reliable path.
You need deeper salvage of the fragment
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) can sometimes reconstruct more from a severely truncated file. Try this tool first for the common case where complete pages survived before the cut.
Frequently asked questions
What does 'unexpected end of file' actually mean?
It means the PDF was cut short and is missing the %%EOF marker, trailer, and cross-reference table that belong at the end of a well-formed PDF — the parts a reader needs to find the objects. The header and the page objects up to the cut are usually intact, which is exactly why this error is so often recoverable.
How does the repair fix it?
The tool loads the truncated file with pdf-lib's tolerant parser, copies every page object it can resolve (i.e. everything before the cut) into a brand-new document, and saves it with a freshly-written trailer, xref, and %%EOF. The output is a valid PDF that opens everywhere — all in your browser, no upload.
Will all my pages be in the repaired file?
Only the pages encoded before the truncation point. PDFs are written front-to-back, so a truncated file contains complete page objects up to the cut and nothing after it. The pages the truncation removed were never saved to disk and can't be recovered by any tool — get a complete copy for those.
Should I repair or just re-download the original?
If the source is still reachable, re-download or re-export — that gives you 100% of the content, while a truncated file is always partial. Use repair when a complete copy is unavailable: it recovers all pages before the cut instantly and privately, turning an unopenable file into a usable one.
Why does the file open in Chrome but not Acrobat?
Lenient viewers like Chrome and Firefox can tolerate a missing trailer and show partial content, while strict readers like Acrobat refuse. Repair produces a formally valid file — with a real %%EOF and a generated xref — so it opens correctly in every reader, not just the forgiving ones.
Is the truncated file uploaded anywhere?
No. The rebuild runs entirely in your browser using pdf-lib and pdfjs-dist. The file never leaves your device. Only anonymous usage counters are recorded when you're signed in.
What if the repair produces no file?
That means the truncation cut the file before any complete page object was written, so pdf-lib can't resolve anything and the load throws. The tool reports the parser error. Re-download or re-export; a desktop tool like qpdf (--recover) may extract fragments from a tiny partial file.
Are there any settings to configure?
No. Repair has no options — it starts automatically when you add the file and does one thing: rebuild the structure by copying the resolvable pages into a fresh PDF with a proper trailer. There's no page selection or quality control, because the goal is to recover everything that survived the cut.
Why are bookmarks, form fields, or metadata missing?
They're document-catalog features stored separately from page content, and they often live near the end of the file — so a truncation may have removed them and a rebuild doesn't carry them regardless. Page content and page-level annotations are preserved. Re-add the rest 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 (truncated) input before the rebuild runs.
Could repairing damage the file more?
No. The tool reads your truncated input and writes a separate new output — the original is never modified. If the rebuild can't help, you still have the original to re-download against or feed to a desktop salvage tool.
My truncated file is encrypted — can repair open it?
Loading uses ignoreEncryption: true, which ignores a stale marker but doesn't decrypt real content. Truncation also frequently damages the encryption structures themselves, so for a genuinely encrypted truncated file a complete re-download is usually the only reliable fix; if you have a complete encrypted copy, decrypt it with PDF Unlock using the password.
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.