PDF password protection explained: encryption vs permissions

“Password-protected PDF” describes two mechanisms that sound similar and are not remotely equivalent. One makes a document unreadable without a secret. The other politely asks software not to let you print. Understanding which you have — and which you are applying — is the difference between a protected document and a false sense of security.

The two passwords

The PDF specification defines two, and a file can carry either or both.

The user password (also called the open password) is the real one. When it is set, the document’s contents are encrypted, and the password derives the key that decrypts them. Without it there is nothing to read: a reader that prompts you before displaying anything is enforcing a user password. There is no bypass, no reader that shows it anyway, and no recovery service with special access.

The owner password (also called the permissions password) governs what a reader is allowed to do with a document it can already open. It carries a set of flags: no printing, no copying text, no editing, no extracting for accessibility.

Why permission flags are not protection

Here is the part that trips people up. When a PDF has only an owner password, anyone can open it — that is the point. Which means the content must be readable. Which means the “do not copy” flag is not preventing access to anything; it is a request recorded in the file that compliant software chooses to honour.

Adobe Acrobat honours it. So do most mainstream readers. But the enforcement lives entirely in the reader, not in the file. Software that ignores the flags can print, copy and extract freely, and doing so requires no cracking of anything — the content was never encrypted.

This is not an obscure weakness. It is how the mechanism is specified. Treat permission flags as a courtesy label — “we would rather you didn’t” — and never as a control over confidential material.

The corollary matters too: if a document you legitimately own refuses to let you copy from it, removing that restriction is not defeating encryption. It is declining a request.

Encryption strength, honestly

When a user password is set, the strength depends on the algorithm:

Revision	Algorithm	Assessment
R2 / R3	RC4, 40–128 bit	Obsolete. RC4 is broken; treat as no protection.
R4	AES-128	Sound. Not the weak link.
R6	AES-256	Current best, PDF 2.0.

AES-128 is not a compromise in any practical sense — there is no known attack that makes a 128-bit AES key guessable. The weak link in an encrypted PDF is almost never the cipher; it is the password, because the key is derived from it. An AES-256 file with the password summer2024 is far weaker than an AES-128 file with twenty random characters.

Which is worth stating plainly about the tool here: the protect PDF tool applies AES-128, verified by reading the bytes of the files it generates rather than taken from documentation. It does not claim AES-256, because the library it uses does not produce it. A tool that overstates its algorithm is telling you something about how carefully it treats everything else.

Choosing a password that carries the weight

Since the cipher is not the weak point, the password is where the effort belongs:

• Length beats complexity. Each added character multiplies the search space. Twenty characters of mixed case, digits and symbols is beyond any practical offline attack.
• A PDF password is attacked offline. Unlike a website login, an attacker with the file can guess as fast as their hardware allows, with no rate limiting. That is precisely the situation where short passwords fail.
• Do not reuse one. A password used elsewhere is only as safe as the weakest place you used it.
• Store it before you need it. There is genuinely no recovery. If the password is lost, so is the document.

The password generator produces suitable ones, and the protect tool can generate one for you in place.

Compatibility

AES-128 has been in the specification since Acrobat 7 in 2005, so support is effectively universal today: Acrobat, macOS Preview, Chrome, Edge, Firefox and the common mobile readers all handle it. AES-256 requires newer software and occasionally trips up older or embedded readers — a real consideration if the recipient’s software is out of your control.

Test that a protected file opens before you rely on it, especially if you are about to delete the original.

Handling the files sensibly

A few habits that prevent the common disasters:

• Keep the unprotected original until you have confirmed the protected copy opens with the password you think you set.
• Send the password separately from the document, through a different channel. Emailing both together protects against nothing.
• Remember the password unlocks, it does not track. Once someone opens the file they have the contents, and can save an unprotected copy. Encryption controls access, not what happens afterwards.
• Removing a password you know is ordinary. People do it constantly with bank statements and payslips already stored somewhere secure. The unlock tool does that, and cannot open a file whose password you do not have.