Set a user password, the one required to open the document. That is the option that encrypts the content with AES-256.
Permission restrictions on their own protect nothing. They are flags that readers agree to honour, and any tool can decline. Use them alongside encryption if you like, never instead of it.
Protecting a PDF looks like a single checkbox and is actually a choice between two mechanisms that share a name and nothing else. One encrypts. The other asks nicely.
The two passwords
Both are called passwords, both are set in the same dialog, and the difference between them is the difference between a locked door and a sign on it.
Actually encrypts the document
- Required before the document will display at all
- Derives the key that encrypts every content stream
- Modern files use AES-256, which has no practical attack
- Without it, the page data on disk is unreadable noise
- This is the one to set
Sets restrictions readers may honour
- The document opens for anyone, no prompt
- Flags request that printing or copying be blocked
- Enforcement is entirely up to the reader application
- Removable in seconds by any tool that declines
- Useful as a signal, useless as protection
What AES-256 actually gives you
PDF encryption has improved a great deal, and current files are in good shape. AES-256 with a properly derived key has no known practical attack, which moves the entire question onto the password.
No practical attack exists. This part of the problem is solved.
Guessing candidates is the only avenue, so length is what protects you.
Length beats complexity. A long passphrase outperforms a short jumble of symbols.
This is worth sitting with. The encryption is not the weak link and has not been for years. Everything now depends on whether the password can be guessed, which means a document protected with the word invoice is not protected, no matter what cipher sits behind it.
Choosing a password worth using
Attack tools try candidates at enormous rates, starting with dictionary words, names, dates and every predictable substitution people make. The defence is not cleverness, it is length.
Use several random words
Four unrelated words are longer, far harder to guess and considerably easier to pass along by phone than eight random characters. Length is what multiplies the work.
Avoid anything about the document
Not the client name, not the project, not the date, not the invoice number. These are the first things any attacker with context will try, and whoever receives the file has all of them.
Never reuse a password you use elsewhere
A document password gets typed into other people's machines and sometimes into websites. Treat it as something that will eventually be seen by someone you did not choose.
Getting the password to the recipient
This is where document protection usually falls apart, and it has nothing to do with the encryption. Emailing an encrypted PDF and then emailing the password puts both halves in the same mailbox, on the same servers, reachable by the same compromise.
Use a different channel. A phone call, a text message, a separate messaging app, or a convention agreed in person beforehand. The channel needs to be different, not necessarily more secure. The point is that compromising one no longer gives up both.
When encryption is the wrong tool
Password protection is good at one thing: stopping someone who has the file from reading it. It does nothing about several problems it is often asked to solve.
- Stop the wrong reader opening itUser password
- Remove secret content entirelyRedaction, then check
- Hide who wrote itStrip the metadata
- Prove it has not been alteredDigital signature
- Stop it being forwardedNot possible with PDF
- Mark it as confidentialWatermark plus a password
The last two deserve emphasis. Nothing in a PDF prevents a recipient who can read it from sharing it, and a password does not change that. And if a document contains something a reader must never see, encryption is the wrong answer, because the encryption comes off for everyone you gave the password to. Remove the content instead.
Protect a PDF with AES-256
Set a password in your browser. The document and the password both stay on your machine.
Common questions
Getting protection right the first time.
01What encryption does PDF protection use?
Current tools use AES-256, which has no known practical attack. Older files may use AES-128 or, further back, RC4 at 40 or 128 bits, which are progressively weaker. For anything created now, the cipher is not the limiting factor. The password is.
02What is the difference between the two passwords?
A user password is required to open the document and encrypts its contents. An owner password leaves the document readable by anyone and only sets flags requesting that printing or copying be blocked. Readers honour those flags voluntarily, so they come off easily.
03What password should I choose?
Several random words, long rather than clever. Avoid anything connected to the document, the client or the date, since those are the first candidates anyone with context will try. Length multiplies the work an attacker has to do far more effectively than adding punctuation.
04How do I send the password to the recipient?
On a different channel from the document. A phone call or text message alongside an emailed PDF is enough. Putting the password in the covering email means the document and its key sit in the same mailbox, which undoes the protection entirely.
05Can I stop the recipient forwarding the file?
No. Once someone can open a document they can share it, and no PDF feature changes that. Restrictions apply to readers, not to people. If forwarding is the actual concern, the document should not contain the content in the first place.
06What if I forget the password I set?
There is no recovery. That is what the encryption means. Save it in a password manager at the moment you set it, because a protected document with a lost password is unreadable to you on exactly the same terms as to everyone else.