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/StandardUses the PDF Standard Security Handler (as opposed to a custom, third-party handler)
/V2Encryption algorithm version 2 — the RC4-based handler with a configurable key length
/R3Security handler revision 3
/Length128128-bit encryption key
/P2147483644Permission 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:

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

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.