Password-protected PDFs, done right

“Just password-protect the PDF” is one of the most common pieces of informal security advice in offices, and one of the most frequently implemented badly. When it is done well it is surprisingly robust. When it is done poorly — which is most of the time — the password is a speed bump for anyone with a couple of minutes and a commodity laptop.

This guide walks through what PDF password protection actually is, where the common mistakes lurk, and how to use it so the protection is real.

Two kinds of PDF password

PDF has two distinct password features, and confusing them is the source of a lot of false confidence.

• Document open password (also called a “user password”). Without it, no one can open the file at all. The file contents are encrypted; the password is what unlocks decryption.
• Permissions password (also called an “owner password”). The file opens freely, but the PDF reader is asked — politely — to block certain operations like printing or copying text unless the permissions password is supplied.

Permissions passwords are not security. They are a suggestion to the reader software, and plenty of readers ignore them. If what you need is “only the recipient can see the contents”, you want a document open password.

The encryption actually matters

Older versions of PDF used weak encryption (RC4, 40-bit keys). Modern PDF — the PDF 2.0 standard, supported by every current major reader — uses AES-256. If the tool creating the PDF offers you a choice, pick the AES-256 option. If the tool does not tell you what it is using, check its documentation. Modern Adobe Acrobat, Apple’s Preview (on recent macOS), and most desktop PDF tools default to AES now; older or simpler tools sometimes do not.

This is the most important technical decision you make. A PDF locked with AES-256 and a strong password is, for any realistic attacker, uncrackable. A PDF locked with RC4-40 can be cracked by a commercial service in minutes.

The password is everything

PDF encryption derives its key from the password. “123456” or the recipient’s first name means there is no security — automated tools will try millions of candidate passwords per second against the file offline, and they will succeed.

NIST’s current guidance on passwords (SP 800-63B) has moved away from “complexity” rules like “must have one symbol” and toward length and uniqueness. For a password that protects a file you are sending across an untrusted channel, think in terms of a passphrase:

• A sequence of 5 or 6 unrelated words, randomly chosen, is both memorable and strong (for example, using a diceware-style list).
• A random 16+ character string from a password manager is equivalent and does not need to be memorable — the password manager will handle it on both ends.

Never deliver the password in the same place as the file

This is the single most common mistake, and it is the one that makes most real-world PDF password protection meaningless.

If you email a password-protected PDF to a client and, in the same email, write “the password is HighStreet2026”, you have protected the PDF against nothing. Anyone who sees the email — a misdirected copy, a mailbox compromise, a backup copy of the email server — sees both the ciphertext and the key.

The password must travel through a different channel from the file. Useful patterns:

• Email the PDF; send the password by SMS or in a Signal message.
• Share the PDF in the client’s cloud folder; hand over the password by phone, with the client confirming they are ready to open the file.
• Use a password the two of you have already agreed on in person, or an ongoing shared secret documented in your client-onboarding paperwork.

For recurring work with a given client, you can standardize the out-of-band channel once and stop thinking about it. For one-off recipients, a text message is almost always fine and almost never as bad as putting the password in the body of the email.

Password-protected PDFs are not the same as end-to-end encryption

A password-protected PDF is an encrypted file. Once the recipient opens it, the plaintext lives on their machine. They can save a copy. They can forward it to other people, and anyone they share the password with can open it. They can screenshot every page.

That is not a weakness of the technology; it is a feature of how documents work. If your use case is “I want to share this document with one person and have strict control over what happens after”, a password is not the right tool; you want a platform with managed access, time limits, and the ability to revoke (Microsoft Purview, some DRM-based document services, or secure client portals that don’t give the file to the recipient at all).

A sensible workflow

Put all of the above together and a useful default looks like this:

1. Generate the password in your password manager: 5-word passphrase or 16+ random characters. Save the entry under the document’s title and the recipient’s name.
2. In whatever tool you use to create the PDF (Acrobat, Preview, a print-to-PDF flow), pick the AES-256 option.
3. Send the PDF.
4. In a different channel — SMS, Signal, a phone call — send the password.
5. For recurring clients, store the recipient’s preferred out-of-band channel in their client record so you do not re-invent this every time.

When the recipient is technical enough to want something better than a password-protected PDF, the upgrade path is to move the document to a client-side-encrypted cloud folder both of you have access to (see the Cloud storage topic). For everybody else, a correctly used password-protected PDF is a very reasonable tool.

It only has to be done right.