How to Password Protect a PDF
Select a PDF, enter and confirm an open password, choose any optional viewer permission settings, and create the protected copy. The tool uses QPDF's 256-bit encryption mode. A separate owner password is generated from crypto.getRandomValues() so the user and owner credentials are not silently reused.
What PDF Encryption Does
PDF encryption protects the encrypted bytes and can require a password before compatible viewers reveal document content. It is different from a web-page password prompt or a password-protected ZIP. The output PDF itself contains a standard PDF security handler.
Open Password vs Owner Password
The open password is the secret recipients use to open the PDF. The owner password controls security settings and gives privileged access in conforming software. Using the same value for both is weaker than keeping them distinct, which is why Basic mode generates a random owner credential locally.
Why 256-bit Encryption Is Used
QPDF recommends 256-bit encryption for modern files. Weak legacy RC4 modes are intentionally not exposed. The output is tested conceptually with both an incorrect and the correct open password so the UI does not call an unchanged PDF protected.
PDF Permissions Explained
Printing, modification and extraction flags are convenience controls used by PDF viewers. They can discourage accidental editing or copying in compliant software, but they are not equivalent to strong digital rights management. Accessibility extraction remains enabled in this implementation.
Choosing a Strong Password
Prefer a unique password of at least twelve characters or a memorable multi-word passphrase. Password strength indicators are guidance rather than proof. If the password is lost, there is no recovery mechanism in this site and the owner password should be stored separately if future policy changes are expected.
Private Browser Encryption
The PDF and both passwords stay inside browser memory. The owner password is created with Web Crypto rather than Math.random(). After the encryption command completes, the QPDF worker is destroyed and virtual input/output files are cleaned.
Troubleshooting
If the source PDF is already encrypted, unlock it with an authorized password before changing its security settings. Large files can require additional memory because the WebAssembly engine holds copies of the input and output. Existing cryptographic signatures can be invalidated by protection changes.
How Password Protection Is Applied
Protect PDF creates genuine encrypted PDF bytes with QPDF rather than adding a visual notice or wrapping the file in another archive format. The default architecture requests 256-bit PDF encryption and validates the result by checking that a wrong password is rejected and the configured open password is accepted. Only after those checks should a protected result be offered for download.
The open password is the value a recipient normally enters to view the document. A separate owner password controls the security settings inside the encrypted PDF. Basic mode generates a high-entropy owner password locally with crypto.getRandomValues() so it is not silently identical to the open password. The generated owner password is displayed only after a successful protection operation so the user can copy it if future permission changes may be needed.
Choosing a Strong Open Password
AES-256 does not make a weak password strong. A short or common phrase can still be guessed. Prefer a unique passphrase of at least twelve characters, especially for confidential documents. Avoid passwords reused for email, banking or other accounts. The strength meter provides guidance without imposing arbitrary character rules that can encourage predictable substitutions.
If the open password is forgotten, this site does not offer password cracking. Keep the password in an appropriate password manager or secure organizational record. For important documents, test the downloaded protected file in a normal PDF viewer before deleting any unprotected working copy.
Owner Password and Permission Flags
Printing, modification and extraction settings are useful for communicating intended use to conforming PDF readers. They are not a substitute for access control. Once an authorized recipient can decrypt and display information, software outside a compliant PDF viewer may still be able to capture that content. The tool therefore describes permission flags accurately rather than claiming that copying or printing can never be bypassed.
Accessibility matters when configuring restrictions. Content extraction used by assistive technology should not be disabled casually. A document that must remain usable by screen readers should be tested in the target viewer after protection.
Why Validation Includes a Wrong Password
A protection UI can look successful even when a library has not actually encrypted the output. The validation sequence specifically attempts to open or inspect the generated file with an intentionally wrong password and then with the correct one. A wrong-password success would be a release-blocking defect because it would mean the supposed protection is not enforcing the configured open password.
Existing Encrypted or Signed PDFs
Changing protection on an already encrypted PDF can require the current password and a separate authorized workflow. The tool does not blindly strip existing protection first. Rewriting encryption also changes document bytes and can invalidate existing cryptographic signatures, so signed source files should be preserved when signature validation matters.
Local Encryption and Memory
The QPDF WebAssembly worker receives a copy of the PDF bytes and password only through browser memory. No document upload endpoint is used. WebAssembly processing can temporarily require significant memory for large files; the worker is destroyed after each operation so input, output and password references are not intentionally retained for later jobs.
Deployment and Recipient Compatibility
Modern PDF viewers generally support 256-bit AES-encrypted PDFs, but organizations using older embedded readers should test compatibility before protecting a large document set. The tool intentionally does not downgrade to obsolete 40-bit RC4 by default merely to support old software. If compatibility requirements demand a weaker mode, that should be a separately documented decision rather than an invisible fallback.
After downloading, open the file in the browsers or desktop viewers your recipients actually use. Check the password prompt, visible page count, printing behavior and any permission-dependent workflow. Permission enforcement differs across readers, which is another reason the interface describes those flags as viewer-enforced policy rather than absolute content control.
The generated owner password can be important for later changes to restrictions. If your organization needs it, copy it into an approved secrets store before leaving the result screen. If it is not needed, do not keep an unnecessary copy. The site does not persist it on your behalf.
Frequently Asked Questions
What encryption is used?
The production command requests QPDF 256-bit PDF encryption.
Are passwords uploaded?
No. They remain in transient browser/worker memory.
What is the owner password?
It controls security settings and is generated separately with Web Crypto in Basic mode.
Can I restrict printing?
Yes: full, low-resolution or none, subject to viewer enforcement.
Can permissions be bypassed?
Viewer permission flags are not strong DRM and should not be described as unbreakable.
What if I forget the password?
This website does not store it and cannot recover it later.
Does protection preserve digital signatures?
Changing encryption rewrites the PDF and can invalidate existing signatures.
Can I protect a PDF on mobile?
Yes if the browser has enough memory for the WebAssembly encryption operation.