How to password-protect a PDF (and what that actually protects)

PDF encryption is genuinely useful and widely misunderstood. The format offers two different passwords that do very different things, and one of them protects considerably less than most people assume.

The two passwords

The user password — real protection

Also called the open password. The document’s contents are encrypted, and without the password there is nothing to read. A reader that does not have it cannot show you the text, because the text is not recoverable.

This is the one that actually protects a document, and it is the one to use when the file contains something that matters.

The owner password — a request, not a lock

Also called the permissions password. The document opens normally for anyone, but it carries flags saying printing, copying or annotating are not allowed. Compliant readers honour those flags.

That is not a flaw in any particular tool; it is how the specification works. Restrictions on a document anyone can open have to be advisory.

Choosing a password that is worth setting

Encryption strength is irrelevant if the password is guessable. An attacker does not attack the cipher; they try passwords.

• Long beats complex. Four unrelated words are stronger and far easier to convey over the phone than a short string of symbols.
• Do not use the recipient’s name, the company name, the project name or the date. These are the first things tried.
• Do not reuse a password you use elsewhere. This one gets shared by definition.

Sending the password

This is where the protection is usually lost. Emailing an encrypted PDF and then emailing the password puts both in the same mailbox, so anyone with access to that mailbox has both.

Send the password by a different route — a phone call, a text message, a different messaging app. Different channel, not just a different email.

What encryption does not do

• It does not stop the recipient sharing the file, or the password. Once someone can open it, they can pass it on.
• It does not stop screenshots or retyping. Anything a person can read, they can reproduce.
• It does not expire. A PDF you sent three years ago opens today with the same password.
• It does not let you revoke access. There is no way to un-send it.
• It does not hide metadata. Title, author and creation date may remain readable in the encrypted file.

For control that persists after sending — expiry, revocation, per-person access — you need a system that holds the document rather than a file you hand over. That is a different tool, and worth knowing you need it.

The other direction: removing a password

If you have the password and want an unencrypted copy — for archiving, or because you must retype it every time — unlocking the PDF produces a decrypted version.

This requires the password. It is for documents you are entitled to open, and removing protection from a document that is not yours may be unlawful regardless of whether it is technically possible.

Where the encryption happens matters

Encrypting a document on a server means uploading the unprotected version first. For a moment, the plaintext document sits on someone else’s machine — which is exactly the situation you were trying to avoid.

Encrypting in your browser avoids that entirely: the document and the password both stay on your device, and only the encrypted result is produced. The password never travels anywhere at all.

A reasonable default

1. Set a user password if the content matters. Skip the owner password unless you specifically want to signal that printing is discouraged.
2. Use four unrelated words.
3. Send the password through a different channel.
4. Check the metadata before sending — see removing metadata before sharing.
5. Accept that this protects the file in transit and at rest, not what the recipient does next.