How to encrypt a pdf before sending it by email
- Step 1Finalise the PDF you intend to attach — Make all edits first — encryption is the last step. Re-editing means decrypting, changing, and re-encrypting, which is avoidable friction.
- Step 2Open the Password Protect tool and drop the file — Load it into the PDF Password Protect tool. One PDF at a time; free tier up to 2 MB / 50 pages.
- Step 3Type the open password — Enter a strong, unique password in the single
Set passwordfield. It becomes both the user and owner password. Don't reuse a password you've sent before — generate a fresh one per send. - Step 4Encrypt and download — qpdf applies AES-256 and you download the encrypted attachment. A blank field is rejected with
Enter a password. - Step 5Attach the encrypted PDF to your email — Add the protected file as a normal attachment. Do not type the password anywhere in the email body or subject.
- Step 6Send the password through a separate channel — SMS, a phone call, or a different secure-messaging app. Tell the recipient they'll need to download the attachment first — email previews won't open an encrypted PDF.
Email-client behaviour with an encrypted PDF
How major clients handle a password-protected attachment. Behaviour is the client's, not the tool's.
| Client / context | Inline preview | What the recipient must do |
|---|---|---|
| Gmail (web) preview pane | Does not open encrypted PDFs | Download, open in a reader, enter password |
| Outlook (desktop/web) preview | Does not open encrypted PDFs | Download, open in a reader, enter password |
| Apple Mail / iOS Mail | Prompts in the Files/Preview viewer | Tap attachment, enter password when prompted |
| Android Gmail app | Opens in the device PDF viewer | Tap, enter password when prompted |
| Webmail with virus-scan attachment block | May reject opaque encrypted attachments | Use a file-share link if the attachment is blocked |
What this tool sets for the email attachment
The browser path uses qpdf-wasm. It encrypts the open gate only.
| Setting | Value applied | Effect |
|---|---|---|
| Open password | Your typed password (user + owner) | Attachment won't open without it |
| Algorithm | AES-256 (256) | Strongest standard PDF encryption |
| Printing | --print=full | Allowed once opened |
| Copying / text extract | --extract=y | Allowed once opened |
| Modifying | --modify=all | Allowed once opened |
Cookbook
Real email-sending scenarios and exactly what the tool produces for each.
One encrypted contract to one client
You're emailing a signed contract PDF. Encrypt it, attach it, and text the password. If the email goes to the wrong person, the attachment is useless to them.
Input: contract-acme-2026.pdf (3 pages, 410 KB)
Field: Set password = "Tg7#nQ2vLp9x"
Email: attach contract-acme-2026.pdf (now encrypted)
body: "Contract attached. Password sent by text."
SMS: "PDF password: Tg7#nQ2vLp9x"
Misdirected to wrong address -> attachment opens to a
password prompt the wrong recipient cannot satisfy.Tell the recipient to download first
The single most common support ticket: "the PDF won't open in Gmail." It's the preview pane, not the file. Pre-empt it in the email body.
Email body template: "The attached PDF is password-protected. Gmail/Outlook previews can't open encrypted PDFs — please DOWNLOAD the attachment and open it in Acrobat, Preview, or your phone's PDF reader. The password is in a separate text message."
Different password per send
Don't reuse one password across recipients or sends. If you generate a fresh one each time, a leaked password only exposes a single message.
Monday -> client A: password "7mK$wpL2qrTz" Monday -> client B: password "Xb4!nv9Hsd6y" Tuesday -> client A: password "Qp2#zr8MkLw5" (new again) A leak of any one password compromises only that one email.
Attachment too large to email — encrypt then link
Even after encryption, big PDFs can exceed mailbox attachment caps (often ~25 MB). Compress and encrypt, then share via a link rather than an attachment.
Step 1 — pdf-compress-lossy: 9.2 MB -> 1.4 MB Step 2 — pdf-password-protect: AES-256 open password Step 3 — upload encrypted PDF to your file share, email the link Step 4 — SMS the password The link is useless without the password even if forwarded.
Encrypted, but the recipient can still forward it
Encryption stops people without the password. It does not stop the intended recipient re-sending the unlocked file or the password. Set expectations; encryption is transport protection, not rights management.
Recipient opens with password -> can Save As, re-attach, or paste the password into a forwarded email. The tool's encryption protects the file in transit and at rest, not after an authorised recipient chooses to share it.
Edge cases and what actually happens
Recipient says the attachment won't open in Gmail/Outlook
ExpectedInline email previews do not open password-protected PDFs. The recipient must download the attachment and open it in a real PDF reader, where the password prompt appears. Add a one-line note in the email body so it doesn't become a support ticket.
Mail server blocks the encrypted attachment as a scanning risk
RejectedSome corporate mail gateways quarantine or strip attachments their antivirus can't scan, and an encrypted PDF is opaque to scanners. If the recipient never receives the file, switch to a file-share link for the encrypted PDF and keep the password out-of-band.
You typed the password into the email body by habit
Defeats the purposePutting the password in the same email (or its subject) means anyone who reads the email also gets the key — the encryption protects nothing. Always send the password through a different channel. The tool can't prevent this; it's a process discipline.
Attachment exceeds the mailbox size cap
Blocked by email, not the toolEncryption doesn't shrink a file. PDFs near or above the ~25 MB mailbox cap should be compressed with the lossy compressor before encrypting, then shared by link. The tool itself caps at 2 MB free / 50 MB Pro.
Empty password field
ErrorThe tool returns Enter a password. and produces nothing. There's no risk of attaching a file you think is encrypted but isn't — the blank case is a hard stop.
The source PDF is already password-protected
Errorqpdf can't re-encrypt a file it can't open, so this errors out (exit code 2). Decrypt with the remove-password tool first, then encrypt for sending.
Recipient forwards the unlocked PDF to others
Out of scopeEncryption is transport and at-rest protection. Once an authorised recipient opens the file, they can re-save and forward it freely (the tool allows printing, copying, and modifying once open). For controlling redistribution you need DRM, which this tool does not provide.
Recipient loses the password
Recoverable by re-sendingNothing about the password is stored, but you know it — just re-send it through the secure channel. If you also lost it, there is no recovery; AES-256 with a strong password can't be brute-forced. Keep the original file until receipt is confirmed.
Frequently asked questions
Does this meet GDPR requirements for emailing personal data?
Encrypting the attachment with AES-256 is a recognised technical measure under GDPR Article 32 (security of processing). It demonstrably reduces the risk of a misdirected or intercepted email exposing personal data. It is one control, not a full compliance program — confirm the overall approach with your DPO.
What encryption is applied to the attachment?
Real AES-256. The browser runs a qpdf WebAssembly build and encrypts with --encrypt <pw> <pw> 256. The unencrypted attachment and the password are processed locally and never uploaded.
Why can't the recipient open it in the Gmail/Outlook preview?
Email preview panes don't support password-protected PDFs. The recipient needs to download the attachment and open it in a PDF reader, which will then prompt for the password. Tell them this in the email so it isn't mistaken for a broken file.
Where do I put the password — in the same email?
Never. Send the encrypted PDF in the email and the password by SMS, phone, or a separate secure message. If the password is in the same email, anyone who reads the email can open the file, which defeats the encryption.
Does encrypting stop the recipient from forwarding the file?
No. Once the recipient opens it with the password they can re-save and forward it (the tool allows printing, copying, and editing after open). Encryption protects the file in transit and at rest, not against an authorised recipient choosing to share it.
My attachment is too big to email — does encryption help?
Encryption doesn't change the size. Compress the PDF first with the lossy compressor, then encrypt, then share by a file-share link if it's still large. The encrypted link is useless without the password even if forwarded.
What if the recipient forgets the password?
Re-send it through the secure channel — you still have it. There's no other way in: the password never reached our servers, and AES-256 with a strong password can't be brute-forced.
Can I encrypt a PDF that's already password-protected?
No — qpdf can't read an encrypted file to re-encrypt it, so the tool errors. Remove the existing password first (you need the current one), then encrypt for emailing.
Will it work with Outlook and Gmail?
Yes. The output is a standard encrypted PDF and attaches like any file in any email client. The only caveat is that inline previews won't open it — recipients download and open in a reader.
Is the unencrypted attachment ever uploaded?
No. Everything happens in your browser via qpdf-wasm. The plaintext PDF and the password stay on your device; only you ever attach the encrypted result to your email.
Should I use a different password for each email?
Yes. A fresh password per send means a leaked password exposes only that one message. Generate them with a password manager so they're strong and unique.
Can the recipient remove the password after receiving it?
Yes, with the Remove Password tool and the password you gave them — useful if they want to archive an unlocked copy on their own secure storage. qpdf decrypts given either the user or owner password (here, the same value).
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.