What Kind of Encryption Does Protect PDF Actually Use?
Published September 2026
Type a password into a "Protect PDF" tool and it's natural to assume something like "bank-grade
encryption" is happening. Nobody tells you which cipher, which key length, or what the password
actually controls once the file is locked. We inspected QuickTools' own Protect
PDF tool directly, at every level, to answer that precisely: the application code, the installed
encryption library's source, and the actual /Encrypt dictionary of a file it produced. The
short answer is that it uses the PDF Standard Security Handler, revision 3, with RC4 encryption and a
128-bit key, not AES. Here's exactly how we know, and what that does and doesn't mean for you.
What Protect PDF Actually Does
The tool's logic is short enough to describe in full. It reads every page of your uploaded PDF, copies each page into a new file, and then calls one encryption function with the password you typed:
reader = PdfReader(input_path)
writer = PdfWriter()
for page in reader.pages:
writer.add_page(page)
writer.encrypt(password)
That's the entire encryption step — a single call, writer.encrypt(password), with one
argument: the password from the form. QuickTools runs PyPDF2 version 3.0.1 to do this
(confirmed directly from the installed package in this project's environment). Nothing else about the
encryption is configured — no algorithm is chosen, no key length is set, no permissions are specified.
Whatever PyPDF2 does by default when you call encrypt() with just a password is exactly
what QuickTools' output contains.
What the PDF's /Encrypt Dictionary Reveals
Rather than trust a description, we generated a real protected file through the actual tool and read its internal encryption dictionary directly — the part of a PDF that records how it was encrypted. Every file we tested (a plain text page, a multi-page document, a page containing an embedded image) produced the identical structure:
| Field | Value | What it means |
|---|---|---|
/Filter | /Standard | Uses the PDF Standard Security Handler (as opposed to a custom, third-party handler) |
/V | 2 | Encryption algorithm version 2 — the RC4-based handler with a configurable key length |
/R | 3 | Security handler revision 3 |
/Length | 128 | 128-bit encryption key |
/P | 2147483644 | Permission flags — see the permissions section below |
This is more informative than anything a PDF viewer's "Document Properties" panel might display,
because it's the file's own record of exactly which handler and revision it used, not a paraphrase.
V 2 / R 3 is a specific, identifiable combination defined in the PDF specification, and it
is not the combination associated with AES.
RC4 vs. AES
PDF supports more than one encryption cipher, and the version number in the /Encrypt
dictionary is what distinguishes them. According to
qpdf's own encryption documentation —
qpdf is a widely used, independent PDF library, and a reasonable authority on this — V 2 is
"an extension of the original algorithm allowing longer keys," part of the RC4 family, while AES only
becomes available starting at V 4 (optionally) and is the only cipher V 5
supports. QuickTools' output is V 2 / R 3, which is RC4, not AES.
This isn't a configuration QuickTools chose against AES — the underlying library's write path doesn't
have an AES option available the way it's currently called. PyPDF2's own
installation documentation
notes that AES support requires an additional optional dependency that this project does not install; the
plain installation PyPDF2 ships with supports the RC4-based handler shown above, and that's the code
path writer.encrypt(password) actually calls. We confirmed this by reading the installed
library's own source rather than assuming it from the documentation alone.
It's also worth being precise about what "128-bit" means here, since it's easy to hear "128-bit encryption" and assume that alone signals strength. Modern PDF tooling generally recommends AES over RC4 specifically because of the cipher, not the key length — qpdf's documentation on weak cryptography characterizes 128-bit RC4 encryption as weak by current standards, independent of the key size, and recommends AES-based encryption for anything created now. QuickTools does not currently offer an option to use AES instead.
What Does the Password Actually Control?
PDF's Standard Security Handler distinguishes between a user password (opens the file
under whatever restrictions are set) and an owner password (opens it with full access,
bypassing those restrictions). PyPDF2's encrypt() function accepts both as separate
arguments — but QuickTools' code only ever supplies one: the password from the form, passed as the user
password. The owner password argument is never set.
Per PyPDF2's own
documentation for this method, when no owner password is given, it defaults to the same value as
the user password. We confirmed the practical effect of this directly: opening a QuickTools-protected
test file with the one password you'd actually type produced PasswordType.OWNER_PASSWORD
from PyPDF2's own password-checking logic — meaning that single password grants owner-level access, not
merely restricted viewing. Entering the wrong password instead returns
PasswordType.NOT_DECRYPTED, and the file's contents remain genuinely inaccessible until the
correct password is supplied.
Does Protect PDF Restrict Copying, Printing, or Editing?
The Standard Security Handler can, in principle, allow a file to be opened while still blocking specific
actions — printing, copying text, editing, filling forms — through the permission flags stored in the
/P field. QuickTools does not set any of these. The value recorded in every file we tested,
2147483644, corresponds exactly to PyPDF2's own default —
ALL_DOCUMENT_PERMISSIONS — every restrictable action left switched on.
In practice, this means Protect PDF functions purely as a password gate: it determines whether the file can be opened at all, and does not layer any additional restriction on top of that once the correct password is entered. It's also worth noting, independent of QuickTools' specific settings, that PDF permission flags are a cooperative signal rather than an enforced lock — qpdf's documentation notes that not every PDF reader necessarily honors every restriction a file requests. QuickTools' files don't request any restriction in the first place, so this distinction doesn't currently apply to its output, but it's a reason not to treat permission flags in general as a security boundary.
What Happens With the Wrong Password?
We tested both directions directly. Supplying the correct password to Unlock PDF decrypts the file cleanly and returns the original content. Supplying an incorrect password does not produce a partially-decrypted or corrupted file — PyPDF2 correctly refuses to decrypt it at all. The underlying rejection works as intended.
One rough edge we found while testing: the current /unlock-pdf route doesn't check whether
decryption actually succeeded before continuing, so a wrong password currently surfaces as a generic
server error rather than a clear "incorrect password" message. That's a real, present behavior of the
tool today, not a claim about the encryption itself — the password check underneath it is working
correctly either way.
What This Does and Doesn't Tell You About Security
It's worth being explicit about what this investigation covers and what it doesn't, since "PDF encryption" gets used as a stand-in for several unrelated things:
- What we verified: the encryption algorithm and key length written into the PDF itself (RC4, 128-bit, via the Standard Security Handler), the password's role as both user and owner password, and the fully permissive permission flags.
- What we did not verify, and this article makes no claim about: how QuickTools transmits your file to and from its server, whether or how long the password itself is retained anywhere, or how the underlying files are stored while being processed. Those are separate questions from what algorithm ends up inside the PDF, and nothing in this investigation established an answer to them one way or the other.
One more thing worth being accurate about: Protect PDF's own tool page rebuilds the file page-by-page rather than copying the original document wholesale, and in testing this means the original file's Title/Author metadata does not survive into the protected copy at all — it's replaced with the library's own default. That's a separate, unrelated side effect of how the file is reconstructed, not a statement about whether metadata is encrypted.
Practical Takeaway
QuickTools' Protect PDF does exactly one thing: it requires a password to open the file, using the PDF format's older but still standards-compliant Standard Security Handler. It's a real, functioning lock for casual sharing — an unauthorized recipient who opens the file in a normal PDF reader without the password genuinely cannot read its contents. It is not currently equivalent to modern AES-based PDF encryption, and it does not add any restriction beyond the open-password itself.
If you specifically need AES-based encryption, a particular key length, separate owner/user passwords with different permissions, or need to satisfy a specific compliance requirement, verify that against what's described here before relying on this tool for that purpose — this isn't a judgment that QuickTools is or isn't adequate for your situation, just a description of what it currently produces so you can decide.
Related Tools
Related Guides
- Passwords, Redaction & Watermarks — how password protection, redaction, and watermarks differ, and which problem each one actually solves.
Frequently Asked Questions
What encryption does QuickTools Protect PDF use?
The PDF Standard Security Handler, revision 3, with RC4 encryption and a 128-bit key. We confirmed this directly from the /Encrypt dictionary of an actual protected file (/V 2, /R 3, /Length 128), and from the installed PyPDF2 library's own source code.
Does Protect PDF use AES?
No. The /V 2 value in the generated file's encryption dictionary corresponds to the RC4-based handler, not AES. AES becomes available in PDF starting at /V 4, and PyPDF2's own documentation notes that AES support requires an additional dependency this project doesn't install.
Is the password used as both the user and owner password?
Yes. QuickTools only supplies one password, and PyPDF2 sets the owner password to the same value when none is given separately. Testing confirmed that entering that password is recognized as the owner password, meaning it grants full access rather than a restricted view.
Does Protect PDF restrict printing or copying?
No. The permission flags in the generated file are set to PyPDF2's fully permissive default, meaning every restrictable action (printing, copying, editing, and others) is left enabled once the password is entered. The tool only controls whether the file can be opened at all.
What happens if I enter the wrong password?
Decryption correctly fails and the file's contents stay inaccessible. On the Unlock PDF tool specifically, a wrong password currently results in a generic server error rather than a clear message, though the underlying password check itself is working as intended.
What happens if I forget my PDF password?
There is no way to recover the file's contents without it. That's an inherent property of password-based PDF encryption, not something specific to how QuickTools implements it. Keep the password somewhere safe before you close the tab.