AES-256 encryption, applied where the file already is. Nothing is uploaded, no account is needed, and the file you hand over opens in any normal PDF reader.
It is AES-256. Specifically, the file gets a PDF standard security handler at revision 6 — V 5, R 6, Length 256, with the crypt filter method set to /AESV3 and both StmF and StrF pointing at it, so the page streams and the strings inside the document are covered, not just one of the two.
There is no RC4 path and no AES-128 path in the code. The older, weaker revisions that a lot of tools still emit by default are simply not options here, because there is no branch that produces them. The handler is written out by hand rather than delegated to a black box, and it is tested against the pdf.js corpus — that is, against files real readers are known to accept, rather than against our own output.
A practical consequence: the person you send the file to does not need this app, or any app in particular. Revision 6 encryption is part of the PDF specification, so a conformant reader handles it — they type the password and the document opens. The implementation here is checked against the pdf.js test corpus rather than only against itself, so what comes out is a file other readers accept, not one that only round-trips with us.
Under the password fields there is a small set of checkboxes headed “Allow the recipient to”. There are four of them: Print, Copy text, Change the document, and Comment and fill in forms. Tick what you want permitted and leave the rest. Those four are the whole list — it is what the PDF permission bits cover, not a shortened version of a longer menu.
One set of permissions applies to the document as a whole. Everyone who has the password gets the same rights; a PDF has no notion of one person being allowed to print and another not.
There is also an optional box: use a separate owner password for full permissions. Tick it and you set two passwords — one you give out, which is bound by the checkboxes above, and one you keep, which is not. Leave it unticked and the same password does both jobs, which is what most people want for a file they are emailing to one colleague.
Search for a way to password protect a PDF and almost every result asks you to upload it. Think about the order of events. You have a document you consider sensitive enough to encrypt. The first thing you are asked to do is send it, unencrypted, across the internet to a machine you do not control, so that a stranger's server can encrypt it and send it back.
The document is at its most exposed at exactly the moment you were trying to protect it. Whoever operates that service has held the plaintext, and the password you typed into their form passed through their machine too. Whatever their retention policy says, the copy existed.
Here the encryption happens where the file already is. The web app does the work inside the page, the desktop app does it locally, and the Chrome extension declares no permissions and no host permissions at all — the browser would not let it reach a server even if something in it tried. The password never leaves the machine you typed it on, because there is nothing for it to be sent to.
Open the document — in a browser tab, in the desktop app on macOS or Windows, or through the Chrome extension from wherever the file already is. Choose the protect tool, type the password, set the four checkboxes, and save. It is free in all three, with no sign-in and no page limit.
It also opens files that are already protected: supply the password and the document loads normally, and it is re-encrypted when you save. Worth knowing on that round trip — the permission flags are not carried over. A file you edit and save comes back encrypted with permissions reset to all-allowed, so if the restrictions matter, set them again on the way out.
Encryption controls who can open a document; it does nothing about what the document says. If part of the text should not reach the reader at all, take it out before you encrypt — you can redact a PDF so the words are removed from the file rather than hidden under a box, and then protect the result.
In a browser tab, with nothing to install, nothing to upload and nothing to sign up for.
AES-256, through the PDF standard security handler at revision 6 — V 5, R 6, Length 256, crypt filter method /AESV3, with both StmF and StrF set to it so streams and strings are both covered. There is no RC4 and no AES-128 path in the code, and the handler is tested against the pdf.js corpus.
Nothing in the app recovers it. The key is derived from the password you typed, so the file does not carry a copy of it anywhere. Keep the unprotected original somewhere safe, or put the password in a password manager before you send the file on. Passwords are capped at 127 bytes, which is a limit in the PDF specification rather than one of ours.
No. Revision 6 AES-256 encryption is part of the PDF specification, so any conformant reader opens the file once they type the password — on a laptop or a phone, in whatever they already use. You only need to get them the password by some route other than the email carrying the document.