A PDF with a strong open password and AES-256 encryption is properly protected: without the password, the content is unreadable. A PDF with only a permissions password is not protected at all in any meaningful sense, and a PDF using RC4 sits somewhere between, on old cryptography you should not rely on for anything that matters.
The word “password” covers all three cases, which is why people get this wrong.
Two passwords that do very different things
PDF defines two passwords, and both are optional.
The user password, which Acrobat calls the Document Open password, is what you are asked for when opening the file. It protects the encryption key. Without it, the bytes are scrambled, and no software can show you the content by ignoring a rule.
The owner password, which Acrobat calls the Permissions password, is meant to control what readers may do once the file is open: print, copy, edit. When it is the only password set, the file has an empty user password, so any reader can decrypt it without asking anybody.
The qpdf documentation states the design plainly: the file’s encryption key is stored in the file, protected by the passwords, and a conforming reader is “supposed to” obey the restrictions. “Supposed to” is the important part. Those restrictions are a request made to the software, and it is up to the software to honour them.
Permissions are an honour system: a demonstration
We encrypted a text PDF with AES-256 (the strongest option), set an owner password, left the user password empty, and denied printing, copying and modification. pdfinfo confirmed the settings:
Encrypted: yes (print:no copy:no change:no addNotes:no algorithm:AES-256)Then we ran pdftotext on it, supplying no password:
$ pdftotext restricted.pdf -
stores file objects format revision offset revision tables page format revision...All the text came out. Next, a three-line pikepdf script opened the file with no password and saved a copy:
import pikepdf
pdf = pikepdf.open("restricted.pdf")
pdf.save("no-restrictions.pdf")pdfinfo reports Encrypted: no for the result. No cracking was involved, and neither password was needed. Even Adobe’s own help page says that recipients using third-party products that do not support these settings can bypass some or all of the restrictions.
Compare a file with a user password. Opening it with no password, or the wrong one, was refused by every tool we tried, as it should be. pdftotext returned Incorrect password and pikepdf raised an error. That is what real encryption looks like.
Permissions still have a use. They prevent casual editing in Acrobat, signal your intent, and can help show that an edit was deliberate. Treat them as a “please do not” sign on an unlocked door.
RC4 and AES: which encryption you get
The password only matters if the cipher behind it holds up. PDF encryption has been through several generations:
| Acrobat compatibility | Cipher | Key length | Status |
|---|---|---|---|
| Acrobat 3 and later | RC4 | 40-bit | Broken. Brute force is practical |
| Acrobat 6 and later | RC4 | 128-bit | Weak, avoid |
| Acrobat 7 and later | AES | 128-bit | Sound cipher, older key derivation |
| Acrobat X and later | AES | 256-bit | Use this |
The Acrobat levels come from Adobe’s password documentation. The qpdf project classes both RC4 options as weak and refuses to write them unless told to, and it sees “no reason to use anything other than 256-bit encryption” unless a file must open in readers from before about 2010. PDF 2.0 (ISO 32000-2) made AES-256 the only encryption method that is not deprecated.
Beyond the cipher itself, PDF’s older schemes derive keys using MD5, which makes guessing passwords cheap. Anyone with a copy of the file can try passwords offline, on their own hardware, as fast as they can, with no lockout to stop them. Newer AES-256 files use a much slower derivation, which is the real reason the jump matters.
To check a file you have received, run pdfinfo file.pdf and read the algorithm: field in the Encrypted line. Our PDF Metadata Viewer shows whether a file is encrypted.
What our tool does, and when not to use it
Our Password Protect PDF tool applies 128-bit RC4, the older standard handler. We verified this on its output: pdfinfo reports algorithm:RC4, and pikepdf reports revision 3. It runs in your browser, so the file and password stay on your device, and any standard reader can open the result.
That makes it reasonable for keeping a file away from casual eyes: a payslip in a shared folder, or a draft on a family computer. It is the wrong tool for files where a determined person would pay to get in. For those, encrypt with AES-256 in Adobe Acrobat, or with free software such as qpdf. In Acrobat, picking “Acrobat X and later” compatibility is what selects 256-bit AES.
What encryption does not protect against
Even AES-256 has limits worth knowing.
- Anyone with the password has everything. Once a file is open, a reader can screenshot it, print to a new PDF or photograph the screen. Passwords protect the file in transit and at rest, not after it is read.
- Weak passwords fall first. A short or common word is exposed to offline guessing whatever the cipher. Use a long random one, such as four or more unrelated words. Our password generator can produce one.
- The password often travels with the file. Sending it in the same email thread defeats the point. Send it by a separate channel, such as a phone call or a different app.
- Encryption does not prove integrity. Researchers showed in the PDFex attacks that encrypted PDFs have no integrity protection, so an attacker can alter an encrypted file so that opening it leaks content to a remote server, in vulnerable readers. Keep your reader up to date, and do not assume an encrypted file is unmodified.
- It does not remove anything. Encryption hides old revisions and metadata from outsiders, but anyone with the password can recover them. Redact properly first.
For truly sensitive files
If exposure would cause real harm (medical records, legal strategy, identity documents, unreleased financials), a PDF password should not be your only layer. In order of preference:
- Do not send a copy at all. A secure portal or a share link with named recipients, expiry and an access log lets you revoke access later. An emailed PDF cannot be recalled once sent.
- Encrypt the file, not just the PDF features. Certificate-based encryption in Acrobat ties access to a recipient’s key rather than a shared password. An encrypted container made with a tool such as 7-Zip with AES-256 also works, and has the advantage of hiding the file’s contents and, if you enable it, file names.
- Use an AES-256 PDF password if the recipient needs a plain PDF. Use a long random password, delivered separately.
Watch for one more trap. Encrypted ZIP files have the same old-versus-new problem as PDFs. We cover the differences in how ZIP compression works.
Removing a password you know
If it is your own file and you know the password, the PDF Unlock Helper can produce an unlocked copy, directly for RC4-encrypted files. For a restricted file you are entitled to edit, ask the owner for an unrestricted version. Nothing here can recover a forgotten open password, and with AES-256 and a good password, that is exactly how it should work.