How to Password-Protect a PDF, and What It Really Protects
You are emailing a document that should not be read by whoever else might see that inbox. A password seems like the obvious answer, and it is a good one — provided you know what it covers.
Encryption on a PDF is genuinely strong at the one job it does. The trouble is that people expect it to do three other jobs it has never done, and the gap between those expectations is where documents get exposed.
A PDF can carry two different passwords
This is the distinction that explains almost everything else, and most guides skip it.
The user password — sometimes called the open password — is required to open the document at all. Without it, a viewer shows a prompt and nothing else. The file’s contents are genuinely encrypted; there is nothing to read until the correct password decrypts it.
The owner password — sometimes called the permissions password — does not stop the document being opened. It marks certain actions as restricted: printing, copying text, editing, and so on. The document opens for anyone, and the restrictions apply to everything that chooses to respect them.
That last phrase is the important one. Permission flags are enforced by convention, not by cryptography. A viewer that honours them will grey out the print button; a viewer that ignores them simply will not. Permissions are a request, and encryption is a lock.
Protect PDF sets a real user password, so opening the file requires it. Alongside that it marks the document as not-to-be-modified and not-to-be-reassembled, while leaving printing and text copying available — sensible defaults for a document you are sending someone to read. Treat the lock as protection and the flags as labelling.
Protecting a document, step by step
- Open Protect PDF and choose your file. It stays on your device.
- Enter a password and confirm it. The strength indicator updates as you type.
- Export. You get a new, encrypted copy; the original unprotected file is untouched on your disk.
The tool requires at least four characters, which is a floor rather than a recommendation — see below. Everything happens in the page: the password is used in memory to derive the encryption key and is never transmitted, logged, or written to browser storage. The reasoning behind processing locally is in how browser-based PDF processing protects your privacy.
There is no recovery, and that is the point
Because nothing about your password leaves your device, there is no record of it anywhere to reset. No support process can recover it, here or in any other tool that encrypts properly. Lose the password and the document is gone — that is what “encrypted” means.
So write it down before you close the tab. A password manager is the right place. The second-best place is anywhere you will still be able to find in six months, which is not a sticky note and not your memory.
If you are the one who set it and you still have it, you can produce an unprotected copy at any time — how to unlock a PDF when you know the password covers that.
Choosing a password worth having
The guidance here has changed, and most advice you will find online is a decade out of date.
The current recommendation from the US National Institute of Standards and Technology, in SP 800-63B, is that length matters far more than composition rules. Forced mixtures of uppercase, digits, and symbols push people toward predictable patterns — a capital at the front, a digit and an exclamation mark at the end — that add much less real difficulty than they appear to.
What actually works:
- Four or five unrelated words beat a short string with substitutions.
correct-battery-village-stapleris both stronger and easier to type thanP@ssw0rd!. - Unique to this document. A password you have used elsewhere is only as strong as the weakest place you used it.
- Not derived from the document. The client’s name, the invoice number, and the date are the first three things anyone would try.
Since you have to communicate this password to your recipient anyway, memorability matters less than you would think. Optimise for length.
Send the password separately. Always.
A password emailed in the same thread as the file protects nothing. Anyone who can read the message with the attachment can read the message with the password.
Use a genuinely different channel: a text message, a phone call, a password manager’s sharing feature. The point is that compromising one channel should not hand over both halves.
What password protection does not do
Encryption controls access to the file. It has no reach past the moment your recipient opens it.
- It does not stop redistribution. Someone who can open it can forward it, along with the password.
- It does not prevent copying in any meaningful sense. The copy-protection flag is a request to the viewer, and the content is decrypted in front of the reader regardless. Screenshots exist.
- It is not rights management. Granting one person view-only access and another editing access is a different technology entirely, one that needs a server checking credentials — the opposite of a self-contained file.
- It does not prove who sent the document, or that it has not been altered. That is what a signature is for; see electronic signature vs digital signature.
- It does not hide the filename. “2026-redundancy-list.pdf” tells the story before anyone types a password.
None of this makes encryption weak. It makes it precise: it protects the file in transit and at rest, and it stops there.
When the recipient cannot open it
The password is correct, they swear, and the file will not open. Four causes account for nearly all of these, in rough order of likelihood.
The password was mangled in transit. A messaging app turned a straight quote into a curly one, or autocorrect capitalised the first letter, or a trailing space came along when they copied it. Ask them to type it by hand rather than paste, and to check for a leading or trailing space — the single most common culprit and the hardest to see.
They are using a viewer that does not handle the encryption. Most modern readers are fine, but some older software, some mobile previewers, and a number of in-browser mail attachment viewers either do not prompt at all or fail silently. Ask them to download the file and open it in a proper PDF reader rather than previewing it in place.
Their system is opening a cached copy. Mail clients and messaging apps keep local previews. If they opened an earlier unprotected version, that is what they may still be looking at.
It is a different file. Two versions in the same folder, one protected and one not, is more common than it sounds — especially when the protected copy was saved alongside the original under a similar name.
If none of that resolves it, send an unprotected copy through a channel you trust and stop debugging. The document getting there matters more than the mechanism.
When a password is the wrong answer
When the sensitive part is one page. Do not encrypt forty pages to protect one. Send the pages the recipient needs — how to extract pages from a PDF — and keep the rest out of the email entirely.
When the recipient will struggle with it. A password-protected attachment defeats many automated systems, some mobile mail clients, and a fair number of people. If the document is going into a workflow, expect it to fail there.
When you need proof rather than secrecy. If the requirement is “show this was not tampered with”, encryption is not the tool.
Where encryption sits in your workflow
Protect last. Every other operation needs the document decrypted, so a file you encrypt first has to be unlocked before it can be merged, split, cropped, or numbered. Assemble the document completely, check it, and encrypt as the final step before sending.
This matters most on bundles. Combine, order, number, verify — then protect. Reversing that order means unlocking and re-protecting at every stage, and each round trip is a chance to save the wrong version. Preparing a PDF bundle for submission walks through that sequence.
If a document you were sent is already encrypted and you need to work with it, unlock it first with its password — Unlock PDF.
The format behind it
PDF encryption is part of the format specification, ISO 32000-2, which defines the security handlers a compliant viewer implements. That is why an encrypted PDF opens with a password prompt in every reader rather than only in the software that created it. The PDF Association publishes accessible material on what the standard covers.
One consequence worth knowing: because encryption is part of the file rather than a wrapper around it, an encrypted PDF is still a PDF. Nothing needs to be installed to open it, and the protection travels with the document wherever it goes.
Keep the original
The protected file is a new copy; your unencrypted source is untouched. Keep it — it is the version you can still edit, and the one you will be glad of if the password turns out to be wrong for the recipient’s software.