Free PDF Password Protect Online

How It Works

1. Upload a PDF file using the drop zone above.
2. Enter an open password (required) and optionally an owner/edit password.
3. Choose encryption strength: 128-bit AES (standard) or 256-bit AES (military grade).
4. Select which permissions to allow (printing and copying).
5. Click "Protect PDF" to apply encryption.
6. Download the password-protected PDF instantly.

Why Protect PDFs?

Password protection ensures that only authorized users can access sensitive documents. Add an open password to restrict who can view the PDF, and an owner password to limit printing, copying, and editing. This is essential for protecting confidential contracts, financial records, medical documents, legal agreements, and proprietary information. Password protection prevents unauthorized distribution and keeps your sensitive data secure.

Password Types Explained

• Open Password · Required to open and view the PDF. Users cannot access the document without this password.
• Owner/Edit Password · Controls permissions like printing, copying text, and editing. Set separately from the open password for additional protection.

Encryption Levels

• 128-bit AES · Standard encryption, widely compatible, fast processing. Suitable for most documents.
• 256-bit AES · Military-grade encryption, maximum security, slightly slower processing. Recommended for highly sensitive documents.

Frequently Asked Questions

What is AES encryption?

AES (Advanced Encryption Standard) is a symmetric encryption algorithm used by governments and organizations worldwide. 128-bit AES is secure for most purposes, while 256-bit AES is military-grade and virtually unbreakable with current technology.

Can I remove a password from a protected PDF?

If you have the owner/edit password, you can remove restrictions. However, if you forget the open password, there is no way to recover it. PDF password recovery is not possible-make sure to save your passwords safely.

Is my PDF secure?

Yes. All processing happens in your browser. Your PDF never leaves your device and is never uploaded to any server. Encryption is applied locally using qpdf (the reference PDF toolkit) compiled to WebAssembly, the first time you encrypt in a session the browser fetches a ~1.3 MB engine file from a CDN, then caches it.

What is the file size limit?

PDFs up to 100 MB can be processed. Processing time depends on file size and encryption level. Larger files with 256-bit encryption may take longer.

What happens if someone bypasses the password?

AES encryption protects the PDF content itself. The password is required to decrypt and view the document. Breaking 256-bit AES encryption with current technology is computationally infeasible.

What "PDF password protection" actually means

The PDF specification distinguishes between two operations that the user interface lumps together as «password-protecting» the file: encrypting the content so the file is unreadable without a password, and restricting what an already-readable file is allowed to do. Both are configured in the same encryption dictionary, both use the same encryption algorithm, but they answer different threat models.

A user password (also called an open password or document-open password) is what you need to type to open the document. The file's content streams (page text, fonts, embedded images) are encrypted with a key derived from this password, so the bytes on disk are ciphertext and no PDF reader can render them without first decrypting. If you forget a user password, the content is gone: no online tool can recover it, and the only realistic recovery options are exhaustive password search with desktop cracking tools or accepting the loss.

An owner password is different. The document is still encrypted, but the open-document operation succeeds without any password input; any PDF reader can render the file. What the owner password protects is the set of operations the reader is permitted to perform, encoded in the 32-bit P field of the encryption dictionary. Bits in P govern printing, copying text, modifying content, filling forms, extracting for accessibility, and assembling pages. This tool sets both: the open password (required) controls who can read the file, the owner password (optional) controls what readers are allowed to do once opened. If you leave the owner password blank, the tool mirrors your open password into the owner slot, which means anyone who can open the file can also do anything with it; setting a separate owner password makes the restrictions meaningful.

How this tool works

This tool uses qpdf, the structural PDF toolkit written in C++ by Jay Berkenbilt and maintained as open source since 2008. qpdf is the reference implementation of PDF structural operations: it is the building block under Ghostscript, PDFtk, most Linux command-line PDF utilities, and a number of cloud PDF services that present themselves as proprietary technology. qpdf implements the standard security handler (Filter /Standard) defined in the PDF specification, which covers every password-based encryption scheme from RC4 40-bit (PDF 1.1, 1994) through AES-256 V=5/R=6 (PDF 2.0, current).

qpdf is compiled to WebAssembly through Emscripten, producing a roughly 1.3 MB module that runs inside this browser tab. The module is loaded lazily, the first time you click Protect, so just visiting the page costs nothing. Once loaded, the browser caches it; subsequent protections in the same session and on future visits are instant. When you upload a PDF, pdf-lib (a smaller JavaScript library) reads the page count and file size for the info display; pdf-lib does not perform encryption, only the metadata read. When you click Protect, the qpdf WASM module receives the PDF bytes through an in-memory Emscripten file system, runs the equivalent of the command-line qpdf --encrypt <user-pw> <owner-pw> <bits> --use-aes=y --print=full/none --extract=y/n --modify=none -- in.pdf out.pdf, and returns the encrypted bytes to the page as a Blob that the page wraps in a download URL.

No network request fires during the encryption. You can verify it: open the browser developer tools to the Network tab before clicking Protect, run the operation, and observe that nothing leaves your machine besides the one-time download of the qpdf module on first visit. A small but useful detail: qpdf accepts 128 as the encryption strength but defaults to RC4-128 for backward compatibility with older PDF tools. This tool always passes --use-aes=y for 128-bit so the UI label «128-bit AES» is honest; 256-bit is always AES (RC4 is not defined at that key length), so the flag is not needed there.

PDF encryption, 1994 to 2026, the algorithms this tool can write

• PDF 1.1 (1994), RC4 40-bit, V=1, R=2. Original spec; the 40-bit key was set by US export-control law of the time. Exhaustible on commodity hardware in seconds in 2026. This tool does not offer RC4-40, because no one should be writing it new in 2026.
• PDF 1.4 (2001), RC4 128-bit, V=2, R=3. Export restriction lifted in 2000; Adobe extended to 128 bits. Still computationally intractable to brute-force, but RC4 itself has known keystream biases that pushed the industry to AES. This tool does not offer RC4-128 either; the «128-bit AES» option always uses AES.
• PDF 1.6 (2004), AES-128 CBC, V=4, R=4. Introduced in Acrobat 7. Same algorithm the US government uses to protect classified information up to the Secret level. Compatible with Adobe Reader 5.0 and later, including legacy enterprise workflows and older mobile readers. This is what the «128-bit AES» option in this tool writes.
• PDF 1.7 Extension Level 3 (2008), AES-256 first revision, V=5, R=5. Adobe introduced this in Acrobat 9. Within a year researchers found a key-derivation flaw that made it weaker than AES-128 in practice. Adobe published a fix. This tool does not write the flawed R=5 variant.
• PDF 1.7 Extension Level 8 (2010), AES-256 corrected, V=5, R=6. Current state of the art. Uses PBKDF2-style key derivation with SASLprep Unicode normalisation, so passwords work consistently across input methods and locales. This is what Acrobat X and later, and every modern PDF tool that exposes «AES-256 encryption,» produces. Compatible with Adobe Reader 9.0 and later. This is what the «256-bit AES» option in this tool writes.
• PDF 2.0 (2017), V=5/R=6 formalised. ISO 32000-2 adopts V=5/R=6 AES-256 as the recommended algorithm and deprecates RC4 entirely. The encryption story stabilises here; subsequent PDF features have not required changes to the encryption layer. Practical guidance: if you don't know your audience's reader version, 128-bit AES is the safer compatibility choice; if you know they have a modern reader (anyone on Acrobat, Apple Preview, Chrome, Edge, or Firefox built in the last decade), 256-bit AES is the safer security choice.

What the permission bits actually do

The P field is a 32-bit integer; each bit grants one operation when set. The PDF specification numbers bits from 1 (least significant) to 32 (most significant) rather than the more customary 0 to 31. The bits in practice: bit 3 (print, with bit 12 further controlling high-quality printing), bit 4 (modify content, mainly text editing), bit 5 (copy and extract text or graphics), bit 6 (modify annotations: notes, highlights, stamps), bit 9 (fill AcroForm fields), bit 10 (extract for accessibility, screen readers depend on this), bit 11 (assemble: insert, delete, rotate pages). This tool exposes the two bits most commonly controlled by end users: print (bit 3, «Allow printing») and copy (bit 5, «Allow copying text and graphics»). It always sets --modify=none behind the scenes, which clears bits 4, 6, 9, and 11 in one shot, a conservative default that says «the file is for reading and printing, not for editing.» Bit 10 (accessibility) stays on so screen readers continue to work.

The hard truth: permissions are advisory. They are honoured by Adobe Acrobat, Adobe Reader, and many commercial readers, and they are routinely ignored by others. Firefox's built-in PDF.js viewer intentionally disregards permission flags; Chrome's viewer largely honours print restrictions but lets you save unrestricted bytes through right-click; most open-source readers (Okular, Evince, MuPDF, SumatraPDF) honour the bits to varying degrees with opt-out settings; and online «PDF permission removers» simply re-write the file with all permissions set, which works without the owner password because the encryption layer was decorative. This tool sets the permissions because the standard says to and because honourable readers respect them. The threat model that permissions defend against is «a recipient using Adobe Acrobat who follows the spirit of the document.» For real prevention, the open password (which is real encryption) is your defence; the owner password is a courtesy.

Choosing a strong password

Password strength matters in the user-password case because the encryption is real: the only attack on a well-encrypted PDF is exhaustive search through the password keyspace. Current NIST guidance (SP 800-63B) is that a single-factor authentication password should be at least 15 characters. The reasoning, well-supported by academic studies and recent breach data, is that length dominates entropy: a 20-character passphrase of common words («correct horse battery staple» style) has roughly 90 bits of entropy and would take centuries to brute-force, while an 8-character mixed-case alphanumeric («Tr0ub4dor») has around 40 bits and falls in hours on commodity GPU hardware.

Practical advice: use a passphrase of 4 to 6 unrelated words, total length 20+ characters. «rotor saxon embargo trout swivel» is far stronger than «P@ssw0rd2026!» and easier to type if you have to read it off a phone. If you use a password manager (1Password, Bitwarden, KeePassXC), generate 20-character random passwords there and save the PDF and its password together; the recipient gets the password out-of-band (a separate email, a phone call, an authenticated channel) and stores it in their own vault. Avoid passwords that appear in breach databases. Do not reuse a password from another service: PDFs sit in inboxes and cloud drives much longer than session cookies, and a password compromised on a forgotten forum in 2018 will still open a 2026 PDF.

Real-world workflows that drive PDF protection

• Confidential contracts to clients or counterparties. The contract is encrypted with a user password shared through a separate channel (often a phone call or a different email address). The owner password adds the restriction that the recipient cannot copy text out of the contract or print it for redistribution. The combination is the standard professional-services workflow for legal, M&A, and financial-deal documents.
• Financial reports for investors. SEC filings are publicly disclosed and unencrypted, but investor-only documents (board packages, quarterly preview drafts, material non-public information) get a user password shared through the investor portal alongside a «do not redistribute» footer. The owner password prevents accidental copy-paste into other internal documents.
• Medical records under HIPAA or equivalent regulations. Patient PDFs are encrypted at rest with a user password tied to the patient or the requesting clinic. The owner password prevents copy-extract of protected health information even when the file is open. The combination satisfies the «encryption at rest» and «minimum necessary use» provisions of most healthcare data regimes.
• Internal company documents with trade secrets. Source code excerpts, hiring rubrics, salary bands. The user password keeps the file inside the company; the owner password limits the reader to printing for review (or blocks printing entirely) so the file does not get photographed and forwarded.
• Client deliverables under a non-transferable licence. The client paid for a custom report. The user password and a cover letter make redistribution at least a deliberate act; the owner password's printing-disabled bit prevents accidental copy through a print-to-PDF re-export workflow.
• Archival migration from legacy encryption. Legacy PDFs encrypted with RC4-40 or RC4-128 are unlocked through PDF Unlock and re-encrypted with AES-256 V=5/R=6 through this tool. This raises the protection level without changing the content. Common when an organisation upgrades its security baseline and revisits old archives.

Common pitfalls and what they mean

• «I forgot the password.» If you forgot the user password, the content is gone. There is no recovery service that does not run exhaustive search against the password keyspace, and exhaustive search through a 15-character password is infeasible on any hardware in 2026. If you forgot the owner password but remember the user password, you can open and re-export the document (any PDF tool will do this, since opening does not need the owner password); the new export will not have the permission restrictions.
• «The recipient cannot open the file.» Two common causes. First, the recipient has an older PDF reader that does not support AES-256, and you protected with 256-bit. Re-protect with 128-bit AES (V=4/R=4), which is supported by every PDF reader since Acrobat 5 (2001). Second, the recipient's reader has trouble with non-ASCII characters in the password and you used non-ASCII characters; SASLprep in V=5/R=6 mostly fixes this, but V=4/R=4 has older encoding quirks. Use ASCII passwords for maximum compatibility.
• «The 'Allow Printing' restriction is being ignored.» The recipient is using Firefox, or a non-mainstream PDF reader, or has used a permissions-removal tool. Permissions are advisory; see «What the permission bits actually do» above. If you need printing to actually be blocked, the only enforcement is social: a non-disclosure agreement, a license, or the recipient's understanding of the document's classification.
• «The digital signature on this PDF is now invalid.» Encrypting a signed PDF rewrites the document bytes, which by definition invalidates the cryptographic signature. If you intend to keep the signature, do not encrypt. If you intend to encrypt, sign after, not before. Some signature workflows (PAdES Long-Term Validation) allow encryption-after-signature but require specific procedures; consult the signature tool's documentation if you need both.
• «Owner password = user password seems to have made the restrictions useless.» Correct. If the owner password is the same as the user password, any reader treats the user as if they have the owner password (because they typed it to open), and the permissions are not enforced. To make permissions meaningful, the owner password must be different and must not be shared with the recipient. This tool defaults to mirroring the user password into the owner slot if you leave it blank, which is convenient for the «I just want to require a password to open» case but defeats the permission restrictions; set a separate owner password when you actually want the restrictions.
• «The PDF is encrypted but still searchable on Google.» If you uploaded the encrypted PDF to a public web server, Google can index its existence (the URL, the filename) but cannot read its content. The file is encrypted on disk and Google would need the password to extract text. The risk is metadata, not content; rename the file before publishing if the filename itself reveals sensitive information.

Browser-only versus cloud protect

Every cloud PDF-protect service (Smallpdf, ILovePDF, PDF24 web, Adobe Acrobat Online, Sejda) uploads the PDF to the operator's servers, encrypts there, and serves the encrypted copy back as a download. The privacy implications differ from a normal file upload in three important ways. First, the file content is by definition unencrypted at the moment of upload (the operator is encrypting it, so the operator has the plaintext). Second, the password you type is transmitted to the operator's infrastructure; even if it is hashed for transport, it exists in plaintext at the encryption step. Third, the operator now holds both the plaintext file and the password, so any compromise of the operator (logs, snapshots, incident response, insider) gives the attacker the file in clear. The major operators publish privacy policies committing to TLS in transit, deletion within hours to one day, and (for the larger ones) ISO/IEC 27001-certified infrastructure, but the threat model that motivates PDF encryption is often inconsistent with handing the plaintext to a third party even briefly.

This tool does not upload the PDF or the password. The qpdf WASM module runs in the browser tab, receives the file bytes through the File API and the password through standard HTML inputs, and returns the encrypted bytes to the same tab. You can prove it: open the browser developer tools to the Network tab before clicking Protect, run the operation, and observe that no requests are made with your file content or password. The only network traffic is the one-time fetch of the qpdf module on the first encryption per session. The trade-off is feature scope: cloud services often bundle OCR, Word/Excel conversion, batch upload, or watermark overlay alongside the encryption. The browser-side encrypt here does just the encryption. For OCR or format conversion the cloud services are the right call; for a sensitive document where the privacy posture matters, the browser is.

More frequently asked questions

Which PDF readers support 256-bit AES encryption?

Adobe Acrobat and Adobe Reader since version 9.0 (2008), Apple Preview on macOS since 10.6 (2009), Google Chrome's built-in viewer since 2012, Microsoft Edge's PDF viewer since 2015, Firefox's PDF.js since 2018, all mainstream iOS and Android readers built since 2015, and qpdf/Ghostscript/Poppler-based open-source readers since the late 2000s. The only readers that cannot open AES-256 are pre-2008 Acrobat versions, some legacy embedded readers in enterprise hardware (ATM consoles, medical devices, industrial controls), and a handful of obscure mobile readers that were abandoned before 2015.

Can I encrypt a PDF that is already encrypted?

Not directly. The tool needs to read the PDF's structure to encrypt it, and an already-encrypted PDF blocks the read until you provide the password. The standard workflow is to unlock the PDF first with PDF Unlock (which requires the existing password) and then encrypt the unlocked output with this tool using a new password. The two-step process is the same pattern used for «migrate from legacy RC4 to AES-256» archival workflows.

Should I encrypt before or after signing, flattening, compressing?

The general order is: edit, flatten, sign, encrypt. Signing computes a cryptographic hash over the document bytes, so any subsequent edit (including encryption) invalidates the signature. Encryption rewrites the document, so flatten before encrypt or the encryption may interact with form-field structure. Compression usually goes before encryption because the encrypted bytes are essentially random and compress poorly afterwards. The full safe order: flatten any form fields you want permanent, compress to reduce size, sign if you need cryptographic provenance, encrypt last to add password protection.

Is encryption equivalent to a password-protected ZIP?

Practically similar at the security boundary (both rely on AES-256), but PDF encryption integrates with PDF readers (the recipient just opens the file and gets a password prompt) while ZIP encryption requires the recipient to extract the file first. PDF encryption also supports the owner-password permission layer (printing/copying restrictions in readers that honour them), which ZIP does not have. For files where the recipient needs to read the PDF in their normal reader, PDF encryption is the smoother choice. For mixed content (multiple files, a folder, non-PDF attachments), ZIP encryption is the only option.

Is PDF encryption sufficient for HIPAA, GDPR, PCI DSS compliance?

AES-256 encryption with a strong password meets the «encryption at rest» technical standard required by HIPAA, GDPR Article 32, and PCI DSS Requirement 3.5. Whether it meets the full compliance regime depends on the rest of your data-handling practices: how the password is shared (out-of-band channels required for most regimes), how access is logged (HIPAA requires an audit trail), and how key rotation is handled. Encryption alone is necessary but not sufficient for compliance; consult your DPO or compliance officer for the full picture.

Is there a desktop or command-line equivalent?

qpdf runs on every platform: brew install qpdf on macOS, apt install qpdf on Debian or Ubuntu, downloadable binaries from the qpdf GitHub for Windows. The CLI syntax for AES-256 encryption is qpdf --encrypt USER-PW OWNER-PW 256 -- input.pdf output.pdf. Same library, same privacy posture as this tool, useful for batch processing through shell loops. Adobe Acrobat Pro's «File > Protect > Encrypt» menu does the same thing with a GUI; for command-line in PowerShell or zsh, qpdf is the closest equivalent.

Related Tools