Protect PDF

What is Protect PDF?

Adding a password to a PDF is one of those operations that everyone needs occasionally and where the practical security depends entirely on the algorithm + password strength, not the UI of whichever tool you use. The PDF spec supports multiple encryption flavours: RC4-40 (legacy, broken since the early 2000s), RC4-128 (legacy, weakened), AES-128 (acceptable), and AES-256 (current best practice). This tool applies AES-256 open-password encryption on the server side: the file uploads to our private worker over HTTPS, gets encrypted with AES-256, returns to your browser, and is deleted from the worker the moment the response sends. We don't keep a copy, and we don't log the password. What we don't do that some marketing pages claim: we don't encrypt "in your browser". Real PDF encryption requires the PDF spec's reference encryption library — there isn't a stable WebAssembly build of it that handles the full feature surface (object-level encryption, AES-256, owner+user passwords), so PDF encryption is genuinely a server-side operation on every reputable tool, including this one. The honesty matters because "browser-only encryption" is often the marketing claim that's falsely reassuring people about a tool that's actually doing the same thing as everyone else.

Why use this tool?

The file uploads over HTTPS to our private worker, gets encrypted with AES-256 (PDF 2.0 / ISO 32000-2 spec), and the encrypted output streams back to your browser. Both the input upload and the encrypted output are deleted from disk the moment the response closes. We don't log filenames, don't persist passwords, and don't telemetry file content. The /security page documents the exact retention. The encrypted PDF works in every reader that supports password-protected PDFs — Adobe Acrobat, Apple Preview, Chrome's built-in viewer, Edge, Foxit, mobile Files apps, every common option that handles modern PDF 2.0 encryption. The recipient is prompted for the password the first time they open it; no special software, no extension, no account on their end. Note on algorithm: we use AES-256 — the current best practice and what regulated industries (HIPAA, certain SOC 2 controls, EU GDPR-Article-32 "appropriate technical measures") expect. Some legacy systems and very old PDF readers (Acrobat 8 and earlier, circa 2007) can't open AES-256 files and need AES-128 or RC4-128. If you're sending to such a recipient, mention it and they can install a modern reader (Acrobat Reader is free).

Common use cases

The recurring case: emailing a contract, NDA, signed agreement, or financial document where the channel (work email, personal Gmail, even encrypted-in-transit channels like Signal) is more trustworthy than the recipient's long-term handling — you want the file unreadable if it ends up forwarded, on a shared drive, or backed up to a cloud service the recipient uses. Adding a password before sending and texting them the password separately means the file is dead to anyone who later finds the email without also having the password. Close seconds: protecting client deliverables before sending (invoices, reports, design comps) so the file can't be casually viewed by the wrong people; preparing tax records for an accountant where the file will sit in their inbox for weeks; securing personal documents (passport scans, ID, medical records) before uploading to a portal or sharing with a service provider. For all of these, the bar isn't "stop a nation-state attacker" — it's "stop the casual reader who comes across the file by accident". A password meets that bar comfortably.

How to use Protect PDF

1. 1Drop your PDF onto the upload area
2. 2Enter a strong password (12+ characters mixing case, digits, symbols recommended). Type it twice to confirm — typos here are unrecoverable
3. 3Click Protect. The worker encrypts the file with PyPDF2 in 1–3 seconds for typical document sizes
4. 4Download the encrypted PDF — the filename gets "_protected" appended
5. 5Send the file and the password through DIFFERENT channels (file by email, password by text/Signal) so a single intercepted message exposes neither

Frequently asked questions

Wait — does my file upload, or does it stay in my browser?

It uploads. We're upfront about this because the alternative ("browser-only PDF encryption") is what most competing tools claim and almost none of them actually do — PDF encryption requires the spec's reference library that doesn't have a complete WebAssembly build. Your file uploads over HTTPS, the worker runs PyPDF2 encrypt(), the encrypted output streams back, and both the input and output are deleted from disk the moment the response closes. We don't log filenames or persist the password. The /security page has the exact retention details.

Which encryption algorithm does this use?

AES-256, the current PDF spec best practice (ISO 32000-2). Implemented via PyPDF2's encrypt(algorithm="AES-256") call. This is the same encryption level Adobe Acrobat's Protect feature produces at its highest setting and what regulated industries (HIPAA-covered entities, SOC 2 environments, certain GDPR-Article-32 obligations) require. The trade-off vs older algorithms (RC4-128, AES-128): readers older than Acrobat 9 (released 2008) can't open AES-256 files. For the modern recipient ecosystem this is the right default; for legacy compatibility specifically, you'd need a different tool.

Can you (or anyone) recover the password if I forget it?

No. We don't store passwords, and the encryption is genuine — without the password, the file is mathematically unreadable. PDF-password-recovery tools (john-the-ripper variants, qpdf brute-force scripts) can sometimes crack short / weak passwords, but they take hours-to-years depending on length and complexity. The practical move is to save the password to a password manager (Bitwarden, 1Password, KeePass, Apple Passwords) at the moment you set it.

Will the encrypted file open in Apple Preview, Chrome, mobile PDF apps?

Yes. The output is a standard password-protected PDF using the PDF spec's encryption — every conformant reader supports it. The recipient gets a password prompt on first open, types it correctly, and the file opens normally. There's no special viewer required and no degradation in rendering.

Can I set both a user password (to open) and an owner password (to restrict editing)?

Currently only the user password (open-password) is supported. Owner-password / permission-bit restrictions (e.g. "open but can't print" or "open but can't copy text") are spec-supported but most readers ignore them, and they provide weaker security guarantees than the open-password — a determined recipient with the right tool can strip the permission bits without knowing the owner password. We don't expose owner-password as a feature because it tends to give users a false sense of security.

My PDF was already encrypted before I uploaded it. What happens?

PyPDF2 needs to read the file first, which fails if the source is already encrypted with a user password we don't know. The tool returns "Cannot encrypt an already-encrypted PDF". Workflow: /pdf/unlock-pdf first (you need the existing password), then re-protect with the new password here. If you don't know the existing password, you can't change it — that's by design, not a tool limitation.

Is a password on a PDF actually useful, or is it security theatre?

It's genuinely useful for the "stop the casual reader" threat model — someone forwarding an email by accident, leaving the file on a USB drive, syncing to a personal cloud, etc. It's NOT a defence against an attacker who has both the file and patience: short passwords can be cracked, and the PDF spec's default algorithms are old. For sensitive data where the threat includes "a competent attacker with time", the right pattern is to ALSO send through an encrypted channel (Signal, end-to-end-encrypted email) and use the PDF password as a second factor.

1. 1Generate the password in your password manager (12–20 random characters), never reuse it across documents — that way a leak on one PDF doesn't cascade to all the others you've sent the same person.
2. 2Test the protection: download the encrypted PDF, open it in your own browser, confirm the password prompt actually appears. If it opens without a prompt, the encryption failed silently — file a bug via /contact.
3. 3For recurring sends to the same recipient (monthly invoices, weekly reports), the password can stay constant per relationship but should be unique per relationship — sharing one password across all clients defeats the purpose.

How does it compare?

Smallpdf and iLovePDF do the same server-side qpdf/PyPDF2 encryption with daily caps and watermark-pushy upsells. Adobe Acrobat's Protect feature is the most capable — supports owner-password granular permissions and certificate-based encryption alongside AES-256 — at $14.99–$23.99/month. PDF-XChange Editor's free tier also supports AES-256. This tool produces AES-256-encrypted PDFs (current PDF 2.0 best practice) at no cost, no daily cap, no upsell. The trade-off vs Acrobat: no owner-password granular permissions (e.g. "can open but can't print") — those bits are spec-supported but most readers ignore them anyway, so we don't expose them as a false-security feature.

Related guides

Editorial walk-throughs that go deeper on the workflow most people use this tool for.

Related tools

More free tools. No signup, no watermarks.