What is PDF encryption?

Encryption in PDF is handled by a security handler, and in practice almost always the standard security handler defined by the specification. When it is in use, the trailer references an encryption dictionary that records the handler, its revision, the algorithm, the key length and a set of values derived from the passwords. The document structure itself — the object numbers and the cross-reference information — stays readable, because a viewer has to navigate the file before it can decrypt anything. What gets encrypted is the payload: string values and stream data, which is where all the content lives.

The key is not the password. The handler derives an encryption key from the password you supply combined with values stored in the encryption dictionary, then uses that key to decrypt streams. Older revisions derived it through repeated MD5 hashing; the current revision uses a much stronger derivation based on SHA-2 with salting. The stored values let a viewer verify that a supplied password produces the right key without the file ever containing the password itself.

Because content streams are encrypted, an encrypted PDF is genuinely opaque without the key. You cannot extract its text, pull its images, or read the words by opening it in a hex editor. This is ordinary cryptography doing ordinary cryptographic work, and it is the reason a lost open password is a real problem rather than an inconvenience someone can talk their way around.

The earliest PDF encryption used RC4 with a 40-bit key. Forty bits was weak even when specified and is not a meaningful defence now; a 40-bit keyspace is simply small. Later revisions allowed RC4 at up to 128 bits, which removed the keyspace problem but kept RC4 itself, a stream cipher since found to have structural weaknesses and now widely retired across the industry. Anything relying on RC4 should be treated as legacy regardless of its key length.

AES-128 arrived with PDF 1.6 as revision 4 of the standard security handler, replacing the cipher with the Advanced Encryption Standard. This was the real improvement: a modern block cipher rather than a patched stream cipher. Revision 4 also introduced crypt filters, which allow different parts of a document to be treated differently — including the option to leave metadata unencrypted so that indexing systems can still catalogue a file they cannot read.

AES-256 is the current position, standardised with PDF 2.0 as revision 6. Beyond the longer key it fixed the password handling: the key derivation uses SHA-2 with salt instead of iterated MD5, and passwords are processed as Unicode under a normalisation rule rather than being squeezed into a legacy byte encoding. An earlier, short-lived AES-256 variant known as revision 5 had a flawed derivation and was superseded, so a file claiming AES-256 is not automatically claiming the fixed version — the revision matters. For anything current, AES-256 at revision 6 is the option to choose, and the practical strength then rests on the password, since a weak password is guessable no matter how good the cipher behind it is.

A PDF can carry two distinct passwords and they do completely different jobs. The user password — commonly called the open or document-open password — is required to open the file. Supply it and the handler derives the key and decrypts the content. Without it there is nothing to read. This is the password that provides actual protection.

The owner password does not gate opening at all. It is the password that grants full rights over the document: it unlocks the permission settings, allowing them to be changed or disregarded. A file can be encrypted with an owner password and an empty user password, which is extremely common, and the result is a PDF that anyone can open with a double-click while its permission flags claim to restrict printing or copying.

That configuration is the source of most confusion about PDF security. Such a file genuinely is encrypted — the streams are ciphertext — but the key is derivable from an empty user password, so every viewer can decrypt it without asking anyone anything. The restrictions that remain are permission flags, and those are requests rather than enforcement. If you want content to be unreadable by people who should not have it, you need a user password. If you set only an owner password, you have expressed a preference, not built a barrier.