Five things "password protect a PDF" guides skip: open vs restrict, what still leaks, and where the password is applied

Most guides to password-protecting a PDF are lists of tools with a checkbox next to "AES". That answers "how do I add a password" but skips the questions that decide whether the password protects anything.

I generated a small PDF with a known title, author and 7 pages, encrypted it four ways with qpdf, and checked what an outsider can and can't get. Here are five questions the tool lists don't cover, with what I measured.

1. Is it a password to open the file, or to restrict it?

A PDF can have two passwords:

• the user (open) password is needed to read the file;
• the owner password controls permissions such as printing, copying or editing.

Many tools and menus say only "password" and set one of these without telling you which. The difference is large. I made a file with an empty open password and an owner password that forbids printing, copying text and editing:

Check on the restricted file	Result
Does a viewer ask for a password?	No, it opens straight away (PyMuPDF needs_pass = 0)
Are the permission bits set to "no print, no copy, no modify"?	Yes (qpdf --show-encryption lists them as "not allowed")
pdftotext on the file	Extracted all 7 pages of text, no password, no warning
PyMuPDF get_text()	Extracted the text
pikepdf.open() then save()	Produced a copy with no encryption and no restrictions, in one step
qpdf --decrypt	Same, no password needed

So a restrictions-only PDF is a polite request that well-behaved viewers honour. qpdf's documentation says it plainly: restrictions are "solely enforced by the software," and any open-source reader "could be trivially modified to ignore" them. PDF24's page says the same in its own words: "PDF programs respect the permissions, but they do not encrypt the content."

If the goal is "only the recipient can read it", you need an open password. Permissions alone are for convenience, not secrecy.

2. What can a stranger still learn without the password?

I encrypted the same file as RC4 40-bit, RC4 128-bit, AES 128-bit and AES 256-bit (all with an open password) and looked at it as someone without the password:

• Content: not readable. pdfinfo answered "Incorrect password", pdftotext returned 0 characters, PyMuPDF asked for authentication.
• Title and author: the plain file contains CONFIDENTIAL-TITLE and HR Dept as readable bytes. In all four encrypted files they were gone.
• Page count: still visible in all four (the /Count 7 entry in the page tree is not encrypted).
• The encryption settings themselves: qpdf --show-encryption printed R = 6 for the AES-256 file even with a wrong password.
• File size: obviously visible.

So the password hides the content and metadata strings, not the fact that a 7-page document exists, or how large it is. For most uses that's fine. For very sensitive documents, know the limit: don't rely on the PDF to hide the size or page count, and don't put anything secret in the file name.

3. Does "AES-256 vs AES-128 vs RC4" matter?

Yes for the old ones, less so between the modern ones.

• qpdf's documentation: 40-bit keys "can be easily brute-forced" and are "not secure regardless of how strong the password is"; the default 128-bit RC4 is "also known to be insecure"; and "there is no reason to use 128-bit encryption with AES" when 256-bit is available. R=6 is the only version not deprecated in PDF 2.0.
• I also measured how long a reader takes to reject one wrong password for each variant (300 attempts, pikepdf from Python, on one machine, so the absolute numbers mean little):

Variant	ms per wrong password
RC4 40-bit	0.09
RC4 128-bit	0.20
AES 128-bit	0.19
AES 256-bit (R=6)	4.2

The AES-256 check was about 22 times slower per guess. That is by design: the newer scheme uses a much heavier hash, which makes each guess costlier for anyone trying many. This is a per-guess cost, not a security rating. A strong password still matters more than the cipher: a short or common password stays weak under any of them. Use a long passphrase, and send it through a different channel from the file.

Compatibility is the usual reason people pick AES-128. I didn't test older viewers; if your recipient uses very old software, ask before choosing AES-256.

4. Where is the password applied?

This is the question I'd ask first. To protect a file with an online tool, you upload the file unprotected, and usually the password too, to a server that adds the encryption. The protection is only as good as that service's handling of your original.

So for a confidential file, check three things on the tool's page: does it say processing is local or on servers, how long files are kept, and whether the page is consistent about it. Here is what each page states (read Nov 2026; "not stated" means I didn't find it on that page):

Option	Where it runs, as stated	Encryption, as stated	Limits and sign-in	Retention
Adobe Acrobat online	"Adobe servers"	Cipher not named; "128-bit key or 256-bit AES" are given only as general examples	No limits stated; sign-in needed to save or share	Deleted unless you sign in to save; no time given
iLovePDF	Not stated	Not named ("Encrypt and protect PDF with a password")	No limits stated; "without registration"	Not stated
PDF24	"In the cloud on our servers" (Germany)	"AES 256 bits"; lists permission options (printing, copying, editing…)	"No limits and no watermarks"; no registration	One hour
Smallpdf	"Smallpdf servers"	"AES 128-bit"	No limits stated; no account	One hour
ToolTiny	The page says both "works entirely in your browser" and that files are deleted "from our servers", so it isn't clear from the page alone	"128-bit AES"; a single open password, no permissions options stated	"Max 20MB"; no account	"Permanently deleted from servers after processing"; no time given. "We do not store your passwords" (the page doesn't say whether the password is sent)
macOS Preview (File → Export → Permissions)	Local desktop app	Strength not stated on Apple's page; has separate open and owner password fields	n/a	n/a
Word "Save as PDF" with "Encrypt the document with a password"	Local desktop app	Strength not stated on Microsoft's page	n/a	n/a
qpdf (command line)	Local	AES-256 (R=6) documented; separate user and owner passwords	n/a	n/a

None of the online options is "the safe one" by itself. What the table shows is that pages differ a lot in how much they tell you: some name the cipher, the location and the retention time; some say none of the three. If a page contradicts itself, test it yourself instead of relying on one line of it. The DevTools → Network tab shows whether your file is uploaded: add the file and look for a large request.

For a file where you can't tolerate any upload, use a local option (the last three rows) and the verification steps below.

5. What a password can't do

• Revoke access. Once someone has the file and the password, you can't take it back or see who opened it.
• Survive a forwarded password. The file is only as private as the channel the password travelled through.
• Hide that the document exists. Page count and size remain visible (question 2).
• Fix a weak password. See question 3.

Check your own result in 2 minutes

# 1. Does it demand a password at all? (should fail without it)
pdftotext protected.pdf -            # expect: "Incorrect password" and no text

# 2. What did the tool actually apply?
qpdf --show-encryption protected.pdf
#   R = 6        -> AES-256; R = 4 -> AES-128 or RC4-128; R = 2 or 3 -> avoid
#   "User password = " (blank) means NO open password: anyone can open it

# 3. Are permissions merely advisory? Strip them to see:
qpdf --decrypt --password=YOURPASS protected.pdf test.pdf   # always on a copy

If step 1 prints the text, you only set restrictions. If step 2 shows a blank user password, same thing.

And to make a file the strong way yourself:

qpdf --encrypt OPEN_PASSWORD OWNER_PASSWORD 256 -- input.pdf output.pdf

Use two different, long passwords. In qpdf, an empty owner password with 256-bit encryption requires an explicit --allow-insecure, because it makes the restrictions pointless.

Limits of this post

• One small file, generated with reportlab and encrypted with qpdf 11.9. I did not test the output of any online tool or desktop app, only what each page states.
• Viewer behaviour varies. I tested poppler, PyMuPDF, pikepdf and qpdf; Acrobat or a browser viewer may handle restrictions differently.
• The per-guess timings come from one machine and include Python overhead. They show a relative difference, not cracking resistance.
• Vendor statements are as they appeared on their pages on the day I read them.

If you've seen a tool apply restrictions when you asked for a password (or the reverse), tell me which one in the comments. It's an easy mistake to make from the menu names alone.