Password protecting a PDF before you email it works best when the encryption happens on your own device. Set an open password and the permission flags in the browser, and the file is encrypted with AES-256 before it goes anywhere.
The order matters more than the algorithm. An upload-based encryptor receives the document first and encrypts it second, so the file is on a server in plain text during that window, and a document you are protecting is by definition one you did not want to expose. Here the PDF is read from your disk into the page, encrypted with a WebAssembly build of qpdf, and handed back as a download. The tool offers one encryption strength, AES-256, because the engine refuses to write the weaker 128-bit and 40-bit forms at all. You also choose an open password, an optional owner password, and whether printing, copying and editing are allowed.
The moment you need this is usually the same moment the risk appears: a payslip, a contract, a medical letter or a set of account details that has to reach one person by email. Email is a plain channel by default, and the attachment travels through at least two mail servers. Encrypting the file before it leaves the device is the part of that workflow you can actually control, and where you do the encryption decides whether it helps at all.
Protect PDF
Add an open password, an optional owner password and permission flags. The file is encrypted with AES-256 in the browser and never uploaded.
Why the encryption step belongs on your machine
The argument for local encryption is not that server tools are dishonest. It is that the order of operations in an upload-based encryptor makes the goal impossible. To encrypt a file, the service has to receive the plain file first, and at that moment the document is unencrypted on a machine you do not own. The password follows the same route and is used there to build the encrypted output. Anything the service logs, caches or keeps for support stays readable until its cleanup runs.
A browser tab inverts that sequence. The PDF is opened from your storage into the page, the encryption is applied there, and only the encrypted bytes are handed back as a download. There is no upload step and no account, and the password never leaves the page. The cost is that the work happens on your device, which is why the tool asks you to keep files under 50 MB and why the engine downloads once, about 1.3 MB, before the first file is processed.
How to password protect a PDF before emailing it
- Add your PDF. Drop the file into the tool. It is read on your device, not uploaded, and if the PDF is already protected the tool says so and asks you to unlock it first.
- Set the password and permissions. Type the open password, repeat it, and add an owner password if you want to change the permission settings later. Then choose whether printing, copying and editing are allowed.
- Protect and download. Tap Protect PDF, check that the summary reports AES-256 next to the file sizes, then download the encrypted copy. Your original file is untouched.
The open password has a minimum of 4 characters and no upper limit, so a short passphrase is possible without fighting the field. The tool checks that the two password fields match before it starts, which avoids locking yourself out of the file with a typo.
Open password vs owner password
The two passwords do different jobs, and only one of them is about access. The open password, sometimes called the user password, is required to open the document at all. Without it, a compliant reader shows a password prompt and nothing else. This is the password you give the recipient.
The owner password governs the permission settings. It is the password a tool asks for when someone wants to change whether printing or copying is allowed. If you leave the owner password empty, the tool reuses the open password for both roles, which is fine for a one-off file that you encrypt and send. Set a separate owner password when the file will stay in circulation and you may want to adjust its permissions later without telling the recipient a new open password.
What the permission flags actually do
Alongside the passwords, three flags describe what the recipient is allowed to do with the document. They map to the standard PDF permission dictionary, which is why PDF readers recognise them.
| Permission | Options | Default | What it controls |
|---|---|---|---|
| Printing | Allow, Block | Allow | Whether a compliant reader lets the document be printed |
| Copying text and images | Allow, Block | Block | Whether text can be selected and images extracted |
| Editing | Allow, Block | Block | Whether the pages can be modified or rearranged |
Read the defaults as the sensible posture for a document you are sending out rather than working on: print allowed so the recipient can make a paper copy, copying and editing blocked so the content is not lifted or altered. If the file is a form that has to be filled in, switch editing to Allow before you encrypt, because a blocked edit flag is honoured by readers that let forms be typed into.
AES-256 only, and why there is no strength picker
Every PDF this tool produces is encrypted with AES-256, and there is no option to choose something weaker. That is not an oversight. The encryption engine is qpdf 11.7.0 compiled to WebAssembly, and that version refuses to write the older, weaker forms at all: ask it for 128-bit and it stops with a message about refusing to write a file with RC4, a weak cryptographic algorithm. Since 40-bit and 128-bit RC4 encryption are no longer considered secure, exposing them as a choice would only let someone produce a file that looks protected but is not.
The random data behind the encryption key comes from the browser's own Web Crypto generator rather than from a predictable source, which is what makes local AES-256 encryption meaningful instead of theatre. One practical consequence: AES-256 needs a reader from roughly the last decade. Every current desktop and mobile reader supports it, but a very old version of a PDF program may refuse the file, in which case the recipient needs to update rather than you needing to weaken the encryption.
What to put in the email, and what never to
Encrypting the attachment only helps if the password travels by a different route. Putting the password in the same message as the file gives an attacker both halves in one place, and a forwarded thread carries the pair along with it.
- Send the file by email. Attach the encrypted PDF exactly as the tool produced it, without further re-saving it in a program that might strip the encryption.
- Send the password separately. A chat message, a phone call, an SMS or a password manager share link all work. Anything that is not the same email thread.
- Say which file it is. If you send several attachments, tell the recipient the file name so they know which password applies where.
- Do not paste the password into the document. A password printed on the page it protects is decoration, not protection.
- Keep a copy of the password. A lost open password cannot be recovered by the tool or by us, because nothing about it is stored.
What this tool does not do
These are the edges of the workflow, and knowing them saves a detour.
- It cannot open an already encrypted PDF. Drop one in and the tool reports that the file is already protected and asks you to unlock it first. Use Unlock PDF with the password you know, then protect the copy.
- There is a 50 MB ceiling. Files larger than that are refused with a message pointing you to split the document or use a desktop tool. Splitting with Split PDF first is one way around it.
- Permissions are a signal, not a lock. Compliant readers honour them, but some third party tools ignore the flags entirely. The open password is the real protection.
- No certificate encryption and no digital signature. This is password based protection, which is what the PDF standard calls it, and it does not verify who the sender is.
- One document at a time. There is no batch mode, so a folder of files is one run each.
- The engine downloads on first use. About 1.3 MB of WebAssembly, cached afterwards. The encryption call itself is synchronous, so the progress bar jumps in steps rather than moving smoothly.
- It does not shrink the file. Encryption adds a small amount of overhead. If the result is too large for the mail server, run the unprotected original through Compress PDF first, then protect the smaller copy.