Protect PDF with Password
Add password protection to PDF files free. Set permissions for printing, copying and editing. Private and instant.
Advertisement
Drop your PDF to protect
Add password protection instantly
Choose PDFAdvertisement
Adobe Acrobat
The world standard for PDFs
Edit, sign, compress, merge, protect PDFs. 500M+ users. 7-day free trial.
Start Free TrialHow to Use This Tool
Upload Your PDF
Upload the PDF you want to protect. The tool shows the current security status of the file.
Set Your Password
Enter a strong password for the user password (required to open). Optionally set an owner password to restrict printing and editing.
Download Protected PDF
Click Protect PDF. Download the password-protected file with AES-256 encryption applied.
Advertisement
Related Tools
Frequently Asked Questions
What encryption standard is used?
What is the difference between user and owner password?
Can the password be removed later?
Is there a file size limit?
About Protect PDF with Password
You are about to email a signed NDA with a vendor's proprietary pricing schedule attached, and email-in-transit encryption is not enough — you want the file itself locked so an accidental forward or email-server breach does not expose the contents. Or your client portal requires uploaded PDFs to be password-protected as a standard data-handling practice, separate from the portal's own access controls. This tool adds a user password (required to open the document) and optionally an owner password (required to modify, print, or extract text). Encryption is AES-256 which is the current PDF spec's strongest cipher — not the legacy RC4 that older tools still apply and which is considered broken for sensitive content. Runs entirely in your browser via qpdf-wasm, so the file and the passwords you set never leave your device. Share the user password through a separate channel from the PDF itself (text message if the file goes over email) because a password emailed alongside the protected file it unlocks gives attackers both halves in a single breach.
When to use this tool
Protecting a signed NDA before emailing
A business-dev lead emails a signed NDA with a vendor's pricing schedule to the vendor's legal team. Adds an AES-256 user password, sends the PDF attachment in email and the password in a follow-up SMS to the same recipient. Email interception or accidental-forward exposure does not reveal contents without the out-of-band password.
Meeting a client portal's data-handling requirement
A consultant uploads deliverables to a Fortune-500 client's SharePoint portal which requires 'all uploaded PDFs must be password-protected' per the client's infosec policy. Set a user password matching the project code (documented in the statement of work), upload, confirm the portal accepts the protected file.
Restricting modification and printing on a distributed draft
A marketing agency sends a creative deck to 30 beta reviewers and wants to prevent casual re-editing or printing. Sets an owner password that restricts modify/print while leaving the user password off (so anyone can open to view). Recipients can read but cannot save altered copies or print physical leaks.
Archiving sensitive records with at-rest encryption
A therapist stores 10 years of session notes as PDFs in a cloud-synced folder. In addition to the cloud provider's at-rest encryption, applies AES-256 password protection on each file so the raw PDF bytes require a second decryption step even if the cloud account is breached. Password is stored in 1Password, not alongside the files.
Distributing exam papers to proctors in advance
A university exam coordinator sends exam PDFs to proctors 24 hours before the test. Protects each file with a user password that is only revealed to the proctor 30 minutes before exam start, preventing a proctor's machine breach from leaking questions in the intervening hours.
How it works
- 1
qpdf-wasm applies AES-256 encryption in your browser
qpdf (the reference PDF command-line tool) implements the full PDF encryption spec including the current AES-256 cipher. We run a WASM build of qpdf inside your browser tab — it reads your PDF into memory, applies the encryption transformation using the password you supply, and writes out an encrypted PDF with the /Encrypt dictionary set. No server processing, no file upload, no password uploaded.
- 2
Two password types are supported independently
You can set a user password (required to open), an owner password (required to modify/print with restrictions), or both. If you set only a user password, the file is fully locked until the password is supplied. If you set only an owner password with restrictions (e.g., disable printing), the file opens freely but cannot be modified or printed without the owner password. Both passwords together give you different access levels for viewers vs editors.
- 3
Permission flags control what viewers can do
The /Encrypt dictionary includes a set of permission flags that readers honor: print, modify, copy text, annotate, fill forms, accessibility extraction, assemble pages. You can set any combination — for example 'allow print low-quality, deny modify, allow copy text' — and viewers like Adobe Reader enforce them. Note that permission flags are honored by convention rather than hard-enforced: some older viewers ignore them, and a determined attacker with the owner password can remove restrictions entirely. Treat permissions as a speed bump, not a wall.
Honest limitations
- · Password protection is only as strong as the password — weak passwords (under 10 characters, dictionary words, birthdays) fall quickly to offline brute force regardless of the cipher strength.
- · Permission restrictions (no-print, no-modify) are enforced by viewer software, not cryptographically; tools like qpdf can strip them given the owner password, and some non-compliant viewers ignore them entirely.
- · Applied encryption invalidates existing digital signatures on the document because the signed byte-range no longer matches the encrypted file layout; protect before signing, not after.
Pro tips
Share the password through a different channel than the file
If you email someone a protected PDF and put the password in the email body or a follow-up email to the same address, an attacker who compromises that mailbox gets both halves together — the protection is effectively zero. Send the file by email and the password by SMS, Signal, or a phone call. This is standard practice for any sensitive document delivery. The few extra seconds to type the password into a second app are more than worth the security improvement, which is often the entire reason to apply protection in the first place.
Use a strong password — passphrases beat random strings
A 6-character password falls to offline brute force within hours on a GPU. A 12-character random password with full character variety is comfortable; a 4-word passphrase (like 'correct horse battery staple') is similar strength and actually rememberable/transcribable without errors. For PDFs distributed to recipients who have to type the password manually (not machine-fed), passphrases produce fewer 'the password did not work' support tickets. Use the password-generator tool's passphrase mode to create one that is both strong and usable.
Do not rely on permission restrictions for security — use a user password
PDF permission flags (no-print, no-copy, no-modify) are enforced by the viewer application, not by the file itself. A determined attacker can remove them with free tools once they have the file open. If you really need to prevent printing or copying, a permission-only owner password is the wrong tool — either accept the recipient might exfiltrate the content (and use the document as leverage rather than as a secret), or apply a full user password so the file cannot be opened at all without the credential. Permission flags work for honest users, not adversarial ones.
Frequently asked questions
What is the difference between a user password and an owner password?
The user password (sometimes called 'document open password') is required to open and view the PDF at all — without it, the reader sees an encrypted blob and a password prompt. The owner password (sometimes called 'permissions password') is required to lift restrictions that were applied at encryption time — for example, to allow printing on a document that was encrypted with 'no print' restriction. You can set either, both, or neither. A PDF with only a user password is fully locked; a PDF with only an owner password opens freely but cannot be modified; a PDF with both requires the user password to open and the owner password to edit.
How strong is the AES-256 encryption?
The cipher itself is cryptographically strong — AES-256 is used for classified-information protection in NATO and US government contexts, and no practical attack against the cipher is known. The practical weakness is the password: PDF encryption derives the AES key from your password via PBKDF2 with 50 rounds (per the PDF spec), which is a low iteration count by modern standards and means a weak password gets bruteforced quickly despite the strong cipher. A 12-character random password with full character variety resists offline attack for centuries; a 6-character password may fall within a day on a GPU cluster. Password strength matters more than cipher choice.
Will my password work in Adobe Reader and other PDF viewers?
Yes. qpdf produces standards-compliant PDF encryption per the ISO 32000 PDF specification, which every major PDF reader honors — Adobe Reader, macOS Preview, Foxit, PDF-XChange, SumatraPDF, Firefox's and Chrome's built-in viewers. The recipient opens the file, gets prompted for the password, supplies it, and the document opens normally. Older readers (Adobe Reader versions below 9, from before 2008) do not support AES-256 and will refuse to open the file; if you need compatibility with antique viewers, select AES-128 during encryption instead (less strong but universally supported since 2005).
Can I remove the password later if I need to?
Yes, with the pdf-password-remover tool on this site — as long as you know the password. Protection is fully reversible by anyone with the password, which is the whole point. Common scenarios: you protected a document for transit, the recipient needs an unprotected copy for their records, you apply the remover and send the unlocked version. Or you protected an archive of documents under an old shared password that has since rotated, you unlock the archive to re-protect with the new password. The remover cannot help if you forget the password — that requires a PDF password recovery tool, not a remover.
Is the file or my password sent to a server during encryption?
No. Encryption runs in your browser via a WebAssembly build of qpdf. The PDF is read into JavaScript heap memory, the WASM module applies AES-256 encryption using the password you typed into the form, and the encrypted output is delivered as a download. Neither the file nor the password make any network round trip. You can verify in the browser's devtools Network tab during encryption — no outbound requests will contain file data or password material. This matters because the whole reason to apply protection is that the document is sensitive, and uploading a sensitive document to a server-side encryption service would defeat the purpose.
Protection is typically the last step before delivery. After pdf-merger assembles the full document, pdf-compressor shrinks it for email caps, and pdf-editor adds signatures or fills forms, protect-pdf applies the password as the final seal. If the recipient later needs to merge the protected PDF with other documents, they will run it through pdf-password-remover first (with the password you shared) since merging requires an unlocked input. For workflows where a document cycles between editing and protection, apply protection only at the end of each cycle rather than repeatedly, since re-encryption each time provides no additional security value.
Advertisement