PDF encryption is genuinely strong — modern files use AES-128 or AES-256, and there is no back door. But whether it protects anything depends almost entirely on two decisions people make casually: which of the two password types they set, and how they send the password.
Get those wrong and you have a document that feels secure and is not.
The two passwords do completely different jobs
The user password (or open password) encrypts the document. Without it, the file cannot be decrypted, cannot be read, and cannot be recovered. This is real cryptographic protection.
The owner password (or permissions password) does not encrypt anything in a way that stops reading. It sets flags declaring that the document should not be printed, copied, or edited. Those flags are advisory — the PDF specification asks viewers to honour them, and well-behaved viewers do. Plenty of tools ignore them entirely, and clearing them takes seconds.
So if you want to stop people reading a document, you need the user password. Setting only an owner password produces a file that opens for anyone, with restrictions that any determined reader bypasses. This confusion is extremely common, and it is why so many "protected" documents turn out not to be.
A useful shorthand: the user password is a lock; the owner password is a sign asking people not to open the door.
Adding a password with what you already have
macOS. Open in Preview, then File → Export as PDF, expand the options, and set a password. Alternatively, from the Print dialogue choose PDF → Save as PDF and set security options. Built in, offline, nothing uploaded.
Windows. No built-in option, but free tools do it locally: PDF24 Creator, PDFsam, or LibreOffice (File → Export as PDF → Security tab, which offers both password types clearly labelled).
Microsoft Word. When saving as PDF, use Options → Encrypt the document with a password. Convenient if the source is a Word file.
Command line. qpdf gives you the most control and the best encryption:
qpdf --encrypt userpw ownerpw 256 -- input.pdf output.pdf
The 256 selects AES-256, the strongest option. Leave the user password empty (--encrypt "" ownerpw 256) if you genuinely only want permissions flags, understanding what that means.
Online tools — Smallpdf, iLovePDF, Sejda and others all offer this. It works, but consider the irony: to protect a confidential document you are uploading it to a third party first. For anything genuinely sensitive, use a local method.
A note on our own tool: Docento.app edits and signs documents in your browser; it does not apply encryption. Use one of the local options above, then edit the unprotected copy and re-protect it afterwards.
Choosing the password
Encryption strength is irrelevant if the password is guessable, and the attacks against PDFs are offline — someone with the file can try billions of candidates without any rate limiting.
- Length beats complexity. Four unrelated words are stronger and far more memorable than
P@ssw0rd!. - Never reuse a password you use elsewhere. This one gets shared with recipients by design.
- Avoid institutional formulas like date of birth or the last four digits of an account number. They are convenient, widely used by banks, and trivially guessable by anyone who knows the person.
- Store it in a password manager at the moment you set it. There is no recovery for a forgotten user password, and no support desk that can help.
Sending the password
This is where most real-world protection fails.
Never send the password in the same email as the document. Anyone who reads the mailbox — an attacker, a mis-sent copy, a shared inbox, a mail server operator — gets both. Encrypting the attachment and pasting the password below it provides essentially nothing beyond the appearance of care.
Send it through a different channel: a text message, a phone call, a separate messaging app, or a password manager's sharing link. If the document and the password travel by different routes, compromising one is not enough.
Two related habits: use a different password for each recipient where practical, so a leak is traceable and revocable; and for recurring exchanges with the same party, agree a shared secret once rather than transmitting a new password every time.
What encryption does not protect against
- The recipient. Once they open it, they can print it, screenshot it, or forward the file and password onward. Encryption controls access in transit, not behaviour afterwards.
- Anything you failed to remove. Metadata, hidden layers, and text sitting under a black box are all encrypted along with everything else — and fully visible to anyone who opens the file. See how to redact text in a PDF.
- A weak password. Offline brute-forcing is unconstrained.
- Old encryption. PDFs using the legacy 40-bit RC4 scheme are breakable quickly. If your tool offers a choice, take AES-256. See AES-128 vs AES-256 PDF encryption.
Working with a protected file afterwards
Encrypted PDFs frequently refuse to load in editors, or load but fail to export correctly. The usual sequence is: unlock, edit, re-protect. How to remove a password from a PDF covers producing an unprotected working copy, after which you can add text, signatures, and annotations and then re-apply encryption before sending.
Remember to re-protect. A document that was carefully encrypted, unlocked for a quick signature, and then emailed unprotected is a genuinely common failure.
When a password is the wrong tool
For a single sensitive attachment to one recipient, encryption is proportionate and effective. For ongoing access by a group, a permissioned share — a link with access control you can revoke, and a log of who opened it — beats a password that spreads and can never be recalled. Passwords have no expiry and no audit trail. See how to share a PDF securely.
