Add password encryption and permission controls to PDF files. Set open passwords and restrict printing or editing — all encryption runs in your browser.
Start with what you get, because the rest of the page is useless if you skip it.
This tool applies real PDF encryption. It writes a standard security handler into the file — AES-256 by default, AES-128 if you need to support readers older than Acrobat X — and derives the encryption key from the password you type. The page content in the downloaded file is ciphertext. Every conforming PDF reader will refuse to display a single page until the password is entered, and your permission choices are written as real permission bits in the encryption dictionary rather than as a note in the metadata.
All of it happens inside your browser. The document is read from your disk into memory, encrypted there, and handed back to you as a download. Nothing is uploaded, and the password never leaves the machine you typed it on. That also means there is no recovery: lose the password and the file is gone, because there is no copy of it anywhere for us to reset. The rest of this page explains what PDF password protection actually is, so you can judge whether it is the right control for what you are sending.
PDF security is defined in the PDF specification (ISO 32000), and it gives a document two distinct passwords that do very different jobs. Almost every misunderstanding in this area comes from conflating them.
| User password | Owner password | |
|---|---|---|
| Also called | Open password, document open password | Permissions password, master password |
| What it does | The reader will not display the document at all until it is entered. It is what unlocks the decryption key for the page content. | Grants full rights over the document and allows the permission settings to be changed. It does not gate opening the file. |
| Actually protects the content? | Yes. Without it, the page data is ciphertext. | No, not on its own. |
| Use it when | Only certain people should be able to read the document. | Anyone may read it, but you want to signal that printing or copying is not intended. |
The critical detail is what happens when a PDF has an owner password but no user password — which is exactly what “restrict printing and copying” features produce. The document is technically encrypted, but it is encrypted with a key derived from an empty user password, so every reader in the world can compute that key and open the file without prompting anyone. The restrictions survive only because conforming readers voluntarily choose to honour them.
“No printing”, “no copying”, “no editing”, “no extracting for accessibility” — these are bits in the PDF's encryption dictionary. They are requests, not enforcement. A reader that follows the specification greys out the Print command; a reader that does not, prints the file. Mainstream commercial readers generally honour them. Many free viewers, browser-built-in PDF renderers, command-line tools and mobile apps do not, and removing the flags entirely takes one command in freely available software.
So the accurate mental model is a sign on a door, not a lock. It is genuinely useful for signalling intent to cooperative colleagues — “this is the read-only reference copy, do not edit it” — and it is worthless against anyone who does not want to cooperate. And even a perfectly enforced no-copying flag would not stop the obvious workaround: a reader who can see the page can screenshot it, retype it, or run OCR over it. There is no way to show somebody a document and simultaneously prevent them keeping it.
The checkboxes in this tool write genuine permission bits, so a conforming reader will honour them — but they are still a sign on a door. The lock is the open password. If the content must not be read by the wrong person, set a password; do not rely on the permission bits to do that job.
When a PDF is genuinely protected, the page content is encrypted and a password derives the key. Which algorithm applies depends on how the file was written:
One point matters more than the algorithm: the strength of a password-protected PDF is the strength of the password. AES-256 behind the password Summer2026 is not protection, because attacking the password is far cheaper than attacking the cipher, and password-recovery tools for PDFs are a mature commercial product category. If you are going to encrypt a file, use a long random passphrase from a password manager.
And the second point, which people skip constantly: a password is only useful if it travels separately from the file. Emailing an encrypted PDF and the password in the same message, or in the next message on the same thread, protects the document from nobody. Send the password by a different channel — a phone call, a text, a password manager share.
The tool on this page is not the only route, and for batches or for files you cannot easily get into a browser these are often better. All of them apply real encryption, and all are available without a subscription except the last.
| Tool | How | Notes |
|---|---|---|
| macOS Preview | Open the PDF, then export it and tick the encryption option, supplying a password. | Built into every Mac. The quickest route if you are already on macOS. |
| Microsoft Word | Save As → PDF → Options → “Encrypt the document with a password”. | Only helps if the source document is a Word file, since it applies at export time. |
| LibreOffice Draw | Open the PDF, Export as PDF, then the Security tab: set an open password, a permissions password, or both. | Free, cross-platform, and it will open an existing PDF rather than only exporting a new one. |
| qpdf (command line) | qpdf --encrypt userpw ownerpw 256 -- in.pdf out.pdf | Free and scriptable, which makes it the right answer for batches. Leaving the user password empty produces the permissions-only case described above. |
| Adobe Acrobat | Protect → Encrypt with password. | Paid, and the reference implementation. |
Before reaching for any of them, ask whether encryption is the right control at all. If the file is going to one person, a share link with an expiry and an access list — from your existing file storage — is usually better: you can revoke it, you can see who opened it, and there is no password to lose. Encrypting a PDF makes sense when the file itself must travel, typically as an email attachment, and you cannot control where it ends up.
For completeness, here is the actual behaviour, so nothing about it is a surprise:
_protected suffix.Two limits are worth stating. The first is that encryption protects the file, not the recipient's behaviour: once somebody has the password they can save an unprotected copy. The second is the password itself — AES-256 behind Summer2026 is not protection, because password-recovery software for PDFs is a mature commercial product and attacking a weak password is far cheaper than attacking the cipher. Use a long passphrase from a password manager, and send it to the recipient through a channel other than the one carrying the file.
If you can open it — you know the password — then yes: open it in a reader and save or export an unprotected copy, or use qpdf --decrypt with the password. If you cannot open it and do not know the password, there is no legitimate shortcut, and a tool promising one is either a brute-force cracker or a scam. Go back to whoever sent it.
Because the content is encrypted, so the parser cannot read the pages. Merging, splitting, compressing and page removal all fail on a password-protected PDF for the same reason, usually with a message about the file being corrupted or encrypted. Decrypt first, do the work, then re-protect the result.
No. It stops them opening it without the password, which is a different thing. Once a recipient has both the file and the password, they can forward both, or simply save an unprotected copy. If forwarding is the risk you are managing, you need access control on a hosted copy, not encryption on a file you handed out.
On its own, rarely. Encryption in transit is one control among several, and frameworks that govern health, financial or personal data generally also expect access control, retention limits, audit logging and a defensible answer to what happens when the recipient leaves their job. Password-protecting the attachment is a sensible step. It is not a compliance programme.