Password Protect a PDF
Password protecting a PDF encrypts the document's strings and streams with AES-256 so it cannot be opened without the password you set. The tool on this page does that locally: it runs qpdf — the standard open-source PDF transformation engine — compiled to WebAssembly in your browser, so the file and the password never leave your device. The password you enter becomes the open (user) password, and you can additionally deny printing or modification; losing that password makes the file unrecoverable, because no reset exists.
How it works
The engine behind the button is qpdf, a C++ library that has been the reference open-source implementation of PDF encryption for two decades, compiled to WebAssembly. On first use your browser downloads the ~1.2 MB engine (program code only, cached afterward); after that, everything runs in the page's sandbox. Your PDF is read into memory, transformed, and handed back as a download — there is no upload step anywhere in the pipeline, which you can verify in your browser's network inspector.
An encrypted PDF is not scrambled wholesale. The file's skeleton — object numbers, the cross-reference table, the page tree — stays readable so viewers can navigate it, while the contents of strings and streams (the text, images, and drawing instructions) are encrypted with AES-256. An /Encrypt dictionary in the trailer records the algorithm, key length, permission flags, and two validation values computed from the passwords. When someone opens the file, their viewer derives the decryption key from the password they type and checks it against those stored values; without the right password, the content is ciphertext and nothing can render it.
The PDF specification defines two passwords with different roles. The user password is the open password: it feeds key derivation, and without it no viewer can decrypt the content. The owner password exists so an author can reopen full control over permissions. This tool sets both to the same value you enter, so there is exactly one password to remember and it genuinely locks the file. The allow/deny choices for printing and modification are stored as bits in the /P entry of the encryption dictionary — and it is worth being honest about what they are: the encryption enforces them only while the file stays encrypted and the viewer chooses to honor them. Any software that has legitimately decrypted the content can ignore the flags. The open password is real cryptography; the permission flags are a polite request.
Algorithm choice matters too. Early PDF encryption used RC4 at 40 and later 128 bits; both are cryptographically broken and were deprecated when ISO 32000-2 (PDF 2.0) standardized AES-256. This tool writes AES-256 only. With a strong passphrase, brute force is the only attack, and its cost is set entirely by password quality — a 4-digit code falls in seconds, a 5-word passphrase effectively never. That is also why "forgot my password" has no technical remedy: the key derivation is one-way by design.
Worked example: protecting a 2.4 MB contract
A 14-page consulting contract, 2.4 MB, dropped onto the widget above on a mid-range laptop. First visit: the qpdf engine downloaded (1.2 MB, about a second on office broadband), then encryption itself took roughly 0.4 seconds. The output, contract-protected.pdf, was 2.41 MB — encryption adds only the small /Encrypt dictionary plus per-stream cipher overhead, since AES neither compresses nor meaningfully expands content. Opening the result in three viewers (Acrobat Reader, Firefox's built-in pdf.js, macOS Preview) prompted for the password in all three, and a wrong password was rejected by all three.
Re-running the same file with "deny printing" ticked produced an identically sized file that Acrobat opened after the password prompt with its Print command greyed out — the viewer honoring the /P flag. That is the two-layer picture in one experiment: the password gate held everywhere, while the print restriction held only where the software cooperated. Choose the password as if it is the only protection, because cryptographically it is.
Frequently asked questions
Does this tool upload my PDF or my password to a server?
No. The encryption is performed by qpdf compiled to WebAssembly, running inside your browser's sandbox; the only network request is the one-time download of the ~1.2 MB engine itself. Your file and your password stay in your device's memory and are never transmitted.
What is the difference between a user password and an owner password on a PDF?
The user password is required to decrypt and open the document at all; the owner password only gates permission settings such as printing or copying. This tool sets both to the same value you enter, so the password you choose is a genuine open password.
Do the no-printing and no-modification options actually stop anyone?
Only in cooperating software, and only while the file remains encrypted. Permission flags are advisory bits that compliant viewers honor, but any tool holding the decrypted content can ignore them, so treat them as a courtesy fence. The open password is the part backed by real cryptography.
Is AES-256 PDF encryption actually secure?
Yes, when it is applied with a strong password: AES-256, standardized for PDF 2.0 in ISO 32000-2, has no known practical breaks. The weak point is always the password, since attackers guess short ones by brute force rather than attacking the cipher.
What happens if I forget the password I set on my PDF?
The content is effectively unrecoverable — there is no reset, recovery link, or backdoor, because the decryption key can only be derived from the password itself. Keep an unencrypted copy in secure storage and record the password in a password manager before distributing the protected file.
Why is there a short download before the first file is processed?
The first use fetches the qpdf WebAssembly engine, about 1.2 MB, which your browser then caches. That download contains only program code — it happens before you pick a file, and no document data ever travels in the other direction.