How to repair a pdf that arrived damaged as an email attachment
- Step 1Save the attachment to disk first — Download the PDF from your email to local storage rather than opening it in the webmail preview. A failed in-browser preview is often a download/preview glitch, not real corruption — saving it and opening it in a desktop reader tells you whether the file itself is damaged.
- Step 2Confirm it's genuinely broken — Open the saved file in two readers. If both fail with 'the file is damaged' / 'failed to load PDF document', the attachment's structure is broken and is a candidate for rebuild. If only the webmail preview failed, just re-save.
- Step 3Open the PDF Repair tool — Go to the PDF Repair tool. It runs in your browser — no upload, which matters when the attachment is confidential.
- Step 4Drop in the saved attachment — Add the
.pdffile. Repair has no options — it starts automatically. Only real PDFs are accepted; a renamed.emlor.datattachment is rejected. - Step 5Download the rebuilt PDF and open it — Save the output. With a freshly-written structure it should open in the strict reader that rejected the original attachment.
- Step 6If content is incomplete, ask for a re-send — Compare the recovered page count to what the email said it should be. If the attachment was truncated in transit and pages are missing, the bytes never arrived — ask the sender to re-attach, ideally zipped or via a file-sharing link so a gateway can't re-encode it.
Why email attachments arrive damaged — and what the rebuild fixes
Each common email-transit failure mapped to whether a structural rebuild can recover it. 'Pages intact' means the page bytes survived and only the structure is broken.
| Cause in transit | What breaks | Rebuild outcome |
|---|---|---|
| Gateway re-encoding / 'sanitising' | Often re-writes the file and breaks the xref or an incremental update; pages usually intact | Recoverable — copy resolvable pages into a fresh document |
| Truncated webmail download | File ends mid-structure; trailer/xref missing; later pages cut off | Partial — pages before the cut are recovered; the rest are gone (re-download / re-send) |
| Base64 / MIME mangling by old mail client | Byte-level corruption scattered through the file; some objects malformed | Often partial — pdf-lib skips bad objects and keeps resolvable pages |
| Stale or gateway-added encryption flag | File marked protected but content is readable | Recoverable — loaded with ignoreEncryption: true |
| Sender's source export was already broken | Structure was invalid before it was ever sent | Recoverable if pages resolve — same as any local corruption |
What survives the rebuild
pdf-lib copies page objects into a fresh document and saves with updateMetadata: false. Page content travels; document-catalog features do not.
| Aspect | Survives? | Note |
|---|---|---|
| Page content (text, fonts, images) | Yes | Copied, not rasterised — quality unchanged |
| Page-level annotations | Yes | Travel with the page they're attached to |
| Bookmarks / outline | No | Catalog object — not carried over |
| Fillable form fields | No | AcroForm is a catalog object; not reconstructed |
| Title / author metadata | No | Fresh empty block (updateMetadata: false) |
| Digital signatures | No | Dropped; bytes change so coverage breaks anyway |
Cookbook
Real attachment-damage scenarios and what the rebuild does. Recovery depends on whether the page bytes actually arrived — a rebuild can't recover content a truncated transfer never delivered.
Invoice attachment broken by a corporate gateway
The accounts-payable team receives a supplier invoice that won't open. The supplier confirms it opens on their side — a classic sign the gateway re-encoded the attachment and broke its structure. The pages are intact.
Symptom: Acrobat "file is damaged and could not be repaired" Sender confirms: opens fine on their machine Repair (pdf-lib reload -> copyPages -> save): 3 page objects resolved and copied into a fresh document Result: clean 3-page invoice opens normally; pass to AP
Truncated download from webmail
A 12-page contract was downloaded over a flaky connection from Outlook web and ends mid-file. Pages before the cut are recoverable; pages after it never arrived.
Expected pages (email body says "12-page agreement"): 12 Repair recovers: 8 -> the download was truncated after page 8. Re-download on a stable connection, or ask the sender to re-send -- the last 4 pages' bytes aren't in the file.
Old mail client mangled the MIME part
A scanned PO from a legacy ERP mailer arrives with scattered byte corruption. pdf-lib's tolerant parser skips the malformed objects and keeps every page it can still resolve.
Repair: pdf-lib skips 3 malformed objects (parser tolerant by default) 5 of 6 pages resolved and copied Result: 5-page PDF. The 6th page's object was unrecoverable; request a re-send of that page or the whole file.
Gateway added a protection flag
A DLP gateway tagged the attachment as protected, and the recipient's reader refuses to open it even though there's no real password. Loading with ignoreEncryption: true clears the block.
Before: reader says "protected", no password works Repair loads with ignoreEncryption: true: pages resolved and copied into a plain document Result: openable, unencrypted PDF. (If it were truly encrypted, you'd need PDF Unlock + password.)
Keeping a medical letter private during recovery
A patient's clinic letter arrives corrupted. Because the whole rebuild happens in the browser, the sensitive content is never uploaded — important for anything covered by privacy rules.
Workflow: 1. save attachment locally 2. drop into PDF Repair (runs in your browser, 0 bytes uploaded) 3. download rebuilt PDF No server ever sees the letter's contents.
Edge cases and what actually happens
The attachment was truncated in transit
Partial recoveryIf the email transfer or your download cut the file short, the missing pages' bytes are simply not present — a rebuild recovers everything before the cut and nothing after it. Compare the recovered count to what the email said. The reliable fix is a re-send or re-download, ideally as a zip so a gateway can't re-encode it.
The file won't parse at all
Parse failedHeavy MIME/base64 mangling can leave a file pdf-lib can't begin to parse. The load throws and the tool surfaces the error instead of producing output. Ask the sender to re-attach the file zipped or share it via a link — that bypasses the encoding step that corrupted it.
A renamed .eml or winmail.dat dropped in
Not supportedSometimes what gets saved isn't the PDF but the raw message part (.eml) or a TNEF wrapper (winmail.dat) renamed to .pdf. The tool accepts only real application/pdf files and rejects these. Open the original message and save the actual PDF attachment, or ask the sender to resend from a non-TNEF client.
Bookmarks / form fields gone after repair
Not preservedThese are document-catalog features, not page content, so a rebuild doesn't carry them. For a fillable form attachment whose values mattered, recover from a backup. Going forward, ask senders to flatten forms, or flatten on receipt with PDF Flatten.
Sender's digital signature is now invalid
Signature invalidatedA rebuild writes new bytes, which breaks any existing signature's coverage. If the signature was the point (a signed contract), don't repair — ask the sender to re-send the original signed file via a link so it isn't re-encoded. Verify the original with the PDF Signature Verifier.
Metadata is blank in the repaired file
By designRepair saves with updateMetadata: false, so the output has a fresh empty metadata block rather than the sender's title/author. This is expected; re-add metadata in your reader if your records system needs it.
Attachment exceeds your tier's limits
Limit reachedFree tier handles attachments up to 2 MB / 50 pages; the size check runs before the rebuild. Large scanned attachments (multi-megabyte) commonly exceed this — upgrade to Pro (50 MB / 500 pages) or Pro + Media (500 MB / 2,000 pages), or ask the sender for a smaller/compressed version.
It was actually the webmail preview that failed, not the file
ExpectedWebmail previewers can fail to render a perfectly good PDF. Save the attachment to disk and open it in a desktop reader before assuming corruption — if it opens there, you never needed repair at all.
The PDF is genuinely password-protected
LimitedignoreEncryption: true ignores a stale/empty marker but does not decrypt real content — it isn't password cracking. If the sender encrypted it, get the password and decrypt with PDF Unlock first, then repair only if it's still structurally broken.
You need raw byte salvage of an unparseable attachment
Out of scopeThis tool rebuilds structure via pdf-lib and won't carve raw bytes from a file pdf-lib can't parse. For a badly mangled attachment, a desktop tool like qpdf (--recover) may reconstruct more — but the most reliable fix for email damage is simply asking for a clean re-send.
Frequently asked questions
Why did the attachment open for the sender but not for me?
Because the damage happened after it left the sender — typically a mail gateway re-encoding the attachment, a truncated download, or an old client mangling the MIME encoding. The original was fine; the bytes you received are broken. If the page content survived and only the structure is damaged, this tool's rebuild produces an openable file.
How does the repair work?
It loads your saved attachment with pdf-lib's tolerant parser, creates a brand-new document, copies every page object whose references resolve, and saves — giving the output a freshly-written cross-reference table and trailer. That's what makes a structurally-damaged attachment openable again. It all runs in your browser.
Is my attachment uploaded to a server?
No. The rebuild runs entirely in your browser using pdf-lib and pdfjs-dist. Confidential attachments — invoices, contracts, medical letters — never leave your device. Only anonymous usage counters are recorded when you're signed in. This is exactly why a browser-based tool suits sensitive email content.
Can it recover an attachment that was truncated in transit?
Only the part that arrived. A truncated transfer means the later pages' bytes were never delivered, so no tool can recover them. The rebuild recovers everything up to the cut. Compare the recovered page count to what the email said — if pages are missing, ask for a re-send, ideally zipped.
Should I repair, or just ask the sender to re-send?
Try repair first when the file is structurally broken but the pages are intact — it's instant and avoids a round-trip. Ask for a re-send when the file is truncated, totally unparseable, or when a valid digital signature matters (a rebuild breaks signatures). For re-sends, request a zip or a file-share link so a gateway can't re-encode it.
Why are bookmarks, form fields, or metadata missing after repair?
They're stored in the document's catalog, not on its pages. The rebuild copies pages into a fresh document and saves with updateMetadata: false, so catalog-level features and the original title/author aren't carried over. Page content and page-level annotations are preserved. Restore the rest in a desktop editor if needed.
What if it says my file isn't supported?
You probably saved the message part (.eml) or a TNEF wrapper (winmail.dat) renamed to .pdf instead of the real attachment. The tool accepts only genuine application/pdf files. Re-open the message and save the actual PDF, or ask the sender to resend from a client that doesn't wrap attachments in TNEF.
Does it work with Gmail, Outlook, and corporate email?
Yes — the tool operates on the PDF bytes, not on where they came from, so any provider's attachment works. Corporate gateways are actually the most common source of damaged attachments, because their security re-encoding can break PDF structure while leaving the pages intact — the ideal case for a rebuild.
Will the repaired file pass through our document system?
It should — the output is a formally valid PDF with a clean structure, which strict validators and DMS importers accept where they'd reject the damaged original. Note that it won't carry the original's metadata or any signature, so if your system keys off those, re-add metadata or re-sign after repair.
How big an attachment 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 before the rebuild runs. Multi-megabyte scanned attachments often exceed the free limit, so a heavy scan may need Pro.
Could repairing damage the file further?
No. The tool reads the attachment and writes a separate new file — your saved original is untouched. If the rebuild can't help, you still have the original to request a re-send or try a desktop tool.
The attachment is genuinely encrypted — can repair open it?
No. ignoreEncryption: true only ignores a stale or gateway-added marker; it doesn't decrypt real encrypted content. If the sender password-protected it, get the password and decrypt with PDF Unlock first, then repair only if it remains structurally broken.
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.