Why Do PDFs Have Passwords? A Brief History

Today it feels obvious that a document format should support encryption. But when Adobe created PDF in 1993, passwords were an afterthought — and their implementation carries the scars of 1990s U.S. export law to this day. Here’s how we got from “no protection at all” to the two- password system that still confuses millions of people every year.

1993–1996: PDF is born, no encryption

PDF 1.0 (Acrobat 1.0, 1993) had no password support. It was a print- ready format — the digital equivalent of a stack of paper. You couldn’t protect a PDF any more than you could protect a fax.

PDF 1.1 (Acrobat 2.0, 1994) introduced the first encryption: 40-bit RC4. This was the strongest cipher Adobe was legally allowed to export outside the United States. The U.S. government classified strong cryptography as a munition — literally in the same legal category as missiles and tanks. Companies that shipped software with encryption above 40 bits faced criminal prosecution.

This is why the first version of PDF encryption was laughably weak by modern standards. It wasn’t that Adobe didn’t know better. They were legally barred from doing better.

The two-password system

The same early specification introduced the split that still exists today: the user password (to open the file) and the owner password (to control permissions).

The logic made sense at the time. Publishers wanted to distribute documents that anyone could read but nobody could modify or reprint. The owner password was designed for that use case — it set flags like “no printing,” “no copying,” “no editing.”

The critical design decision: the owner password does not encrypt the content. It’s stored as a hash inside the PDF metadata. Any reader that ignores the flags can access the content freely. This was a deliberate trade-off: Adobe wanted the file to open without a prompt when only the owner password was set, so users wouldn’t be confused by a password dialog for a document they were supposed to read.

That trade-off is why, thirty years later, owner passwords can still be removed in milliseconds.

1999–2001: export laws relax, encryption improves

In 1999, the U.S. Bureau of Industry and Security significantly relaxed its encryption export controls. Software with strong cryptography could now be exported to most countries without a special license.

Adobe moved quickly. PDF 1.4 (Acrobat 5.0, 2001) introduced 128-bit RC4. This was a massive jump — from 2^40 possible keys to 2^128. Brute- forcing the key space went from “trivial on a PC” to “impossible for any computer that will ever exist.”

But the password is not the key. The password is hashed to derive the key, and most passwords have far less than 128 bits of entropy. A dictionary of 14 million common passwords can be tested in seconds. The encryption algorithm was now strong; the human element remained the weak link.

2006: AES enters the picture

PDF 1.6 (Acrobat 7, 2006) added support for AES-128 as an alternative to RC4. AES (Advanced Encryption Standard) had been adopted by the U.S. government as its standard symmetric cipher in 2001, and the industry was moving away from RC4, which had known statistical biases.

The switch to AES was a straightforward upgrade in security. AES is a block cipher with no known practical attacks. For PDF users, the experience was identical — set a password, get an encrypted file — but the underlying mathematics was significantly stronger.

2008: AES-256 and the modern era

PDF 1.7 Extension Level 3 (Acrobat 9, 2008) introduced AES-256. This remains the strongest encryption available in the PDF specification as of 2026. Acrobat 10 (2011) refined the key derivation to use a more secure algorithm, closing a weakness in Acrobat 9’s implementation that allowed certain shortcut attacks.

With AES-256 and a strong password, a PDF is genuinely secure. The key space is astronomical — 2^256 is more than the number of atoms in the observable universe. No amount of GPU power will brute-force the key.

The only practical attack is on the password itself: dictionary attacks, rule-based mutations, and brute-force of short passwords. That’s what tools like hashcat do, and it’s what PDFUnlock uses for password recovery.

Why we still have the two-password problem

The owner/user password split has persisted for thirty years because it serves two genuinely different use cases:

Access control (user password): “Nobody should read this without the password.” Used for tax returns, medical records, legal contracts.
Usage control (owner password): “Everyone should read this, but nobody should modify or reprint it.” Used for reports, forms, branded documents.

The problem is that most people don’t understand the distinction. They set an owner password thinking they’ve “locked” the file, when in reality they’ve only asked PDF readers to be polite about restrictions.

Where things stand in 2026

The PDF 2.0 specification (ISO 32000-2) keeps AES-256 as the only recommended encryption algorithm and drops support for RC4. In practice, millions of older PDFs with RC4 encryption still circulate, and most PDF tools still support them for backwards compatibility.

The encryption is now excellent. The password practices are still terrible. That gap — between mathematically unbreakable encryption and password123 — is why services like PDFUnlock exist, and why they will continue to exist for a long time.

What this means for you

If your PDF uses RC4-40: it can be cracked regardless of password strength. Upgrade your tools.
If your PDF uses AES-256 with a strong, random password: it’s as safe as anything in civilian computing.
If your PDF has only an owner password: it’s not encrypted at all. Remove it for free.
If you’ve lost a user password: upload your PDF and we’ll give you an honest assessment of recovery chances before you pay anything.