Free · Fast · Privacy-first

PDF Decryption Online

PDF encryption in real world documents uses AES 256, AES 128, or legacy RC4 ciphers depending on the PDF specification version and the tool that produced the file. Modern PDFs from current versions of Acrobat and Office use AES 256 with the latest key derivation, while older files from the early 2000s still circulate with weaker RC4 protection. FixTools decrypts all standard PDF encryption algorithms directly in your browser through a JavaScript implementation built on the Web Crypto API for AES and a small pure JavaScript routine for RC4. Enter the correct password and the browser derives the document key using the algorithm specified in the encryption dictionary, then decrypts the content streams and writes a clean unencrypted PDF, all without sending any data to a server during the process.

⚡ Use Tool Now How it works

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

⚡

Supports AES-256, AES-128, RC4-128, and RC4-40 encryption

🔒

Handles PDF 1.1 through PDF 2.0 security revisions

✨

Browser-based decryption, zero server transmission

PDF Tool

Unlock PDF

All processing happens in your browser — your files are never uploaded to any server.

🚀Open Unlock PDF

100% Free · No account · Works on any device

PDF encryption algorithms: RC4, AES, and how password key derivation works

The PDF specification has used several encryption algorithms across its version history and each generation of the format introduced stronger cryptography to keep pace with evolving attack capabilities. PDF 1.1 through 1.3 used RC4 with a 40 bit key, now considered cryptographically weak and trivially brute forced on modern hardware in minutes. PDF 1.4 and 1.5 introduced RC4 with a 128 bit key, providing significantly more resistance to attack although the RC4 cipher itself has known weaknesses that make it unsuitable for new designs. PDF 1.6 added support for AES 128 bit encryption with Cipher Block Chaining mode and an initialisation vector per content stream. PDF 1.7 standardised as ISO 32000 dash 1 extended this to AES 256 bit with a different key derivation process introduced in Revision 5. PDF 2.0 standardised as ISO 32000 dash 2 uses AES 256 with Revision 6 key derivation, which uses UTF 8 password encoding and SHA 256 as the underlying hash function.

The password a user enters is not directly used as the encryption key for the content streams. Instead, a key derivation function processes the password, the document's file identifier which is a unique 16 byte value embedded in the PDF's trailer, and in some revisions a random salt value, to produce the 40 bit, 128 bit, or 256 bit document encryption key that the cipher actually uses. For Revision 2 covering RC4 40 bit and Revision 3 covering RC4 128 bit, MD5 hashing is used iteratively in the key derivation process. For Revision 4 covering AES 128 bit, the same MD5 based derivation is used with the AES cipher filter substituted for RC4. For Revision 5 and 6 covering AES 256 bit, SHA 256 is used with separate user and owner password salts and an additional validation round.

This key derivation architecture means that two PDFs encrypted with the same password produce different encryption keys, because the file identifier and salts differ between documents. It also means that verifying a password requires recomputing the key derivation and checking it against a stored hash, specifically the /U entry for user password verification and the /O entry for owner password verification in the encryption dictionary. FixTools performs this verification and the subsequent decryption entirely in JavaScript using the Web Crypto API for AES operations with hardware acceleration where available, and a small JavaScript implementation for legacy RC4 since RC4 is deliberately omitted from the Web Crypto API. The result is a decrypted PDF written to browser memory and offered as a download, with the encryption dictionary stripped from the output file.

Understanding the algorithm and revision your PDF uses helps explain what to expect from any decryption tool. PDFs created today by current Office and Acrobat versions default to AES 256 Revision 6 with UTF 8 passwords, which is currently considered cryptographically strong as long as the password itself has sufficient entropy. PDFs from corporate document management systems that have not been updated may still produce AES 128 or even RC4 128 files. PDFs from legacy archives going back to the late 1990s may use RC4 40 bit which is weak enough that the document can be opened without knowing the password at all by tools that perform exhaustive key search. FixTools handles every algorithm and revision the specification covers, so the tool works regardless of which generation produced the file.

PDF 32000-1: Section 7.6, Encryption NIST FIPS 197, AES specification

How to use this tool

💡

Upload an encrypted PDF and enter the decryption password. FixTools identifies the encryption algorithm and decrypts the file in your browser.

How It Works

Step-by-step guide to pdf decryption online:

1
Open the Unlock PDF tool
Visit fixtools.io/pdf/unlock-pdf in any modern browser. No account creation is required, no download installer is offered, and no registration form blocks access. The page loads as static assets and is ready to accept your encrypted PDF immediately. The decryption engine initialises inside the tab during the initial load.
2
Upload the encrypted PDF
Select the password protected PDF through the file picker or drag it onto the upload area. FixTools reads the encryption dictionary header to identify the algorithm version including the cipher type, key length, and revision number. The detected algorithm determines which key derivation path will run when you submit the password.
3
Enter the password
Type the user password or owner password into the password field. The browser runs the appropriate key derivation function for the document's revision, hashes the candidate password with the file identifier and any salts, and verifies the result against the stored /U or /O hash to confirm the password is correct before proceeding to content decryption.
4
Download the decrypted PDF
Click the Unlock button. The decrypted content streams are written to a new PDF without an encryption dictionary and the result is downloaded to your device through a standard browser download. The output is a clean unencrypted PDF that opens in any reader without a password prompt and with all permissions cleared.

Real-world examples

Common situations where this approach makes a real difference:

Decrypting a legacy PDF encrypted with RC4-40

An archivist at a historical society recovers PDF documents from a 2001 era document management system that has been sitting on a shelf since the original organisation merged. The PDFs used RC4 40 bit encryption which was the standard available at the time of creation and was considered adequate for the documents' sensitivity. FixTools handles the legacy RC4 algorithm using its built in JavaScript RC4 implementation and decrypts the documents cleanly for migration to a modern archive system that does not support encrypted PDFs at ingest, completing the migration in an afternoon rather than as a multi week project.

Verifying which encryption algorithm a PDF uses

A security auditor at a financial services firm needs to confirm that the organisation's PDF generation workflow produces AES 256 bit encrypted files using Revision 6 key derivation rather than the weaker RC4 128 bit algorithm that an older library default might still produce. By opening a sample PDF in FixTools and observing the encryption dictionary details surfaced during the unlock process, they identify the exact algorithm and revision in use and report on compliance with the internal data protection security policy that mandates AES 256 for any document containing client information.

Decrypting a PDF 2.0 document with AES-256 Revision 6

A developer working with PDF 2.0 files conforming to ISO 32000 dash 2 needs to process AES 256 Revision 6 encrypted documents as part of a new document processing pipeline being built for a client. They use FixTools as a reference implementation to verify that the decryption output is byte for byte correct before building the automated pipeline against their internal library, confirming that UTF 8 password handling, SHA 256 key derivation with proper salting, and the new validation key checks all work as the standard specifies and that no edge cases break their downstream parsers.

Bulk preparation of encrypted bank statements for accounting software

An accountant preparing a client's year end accounts receives twelve monthly bank statement PDFs, each encrypted with AES 128 and the same password derived from the client's account number. They unlock each one using FixTools in succession through the browser interface to produce unencrypted copies that can be imported directly into their bookkeeping software, which does not accept encrypted PDF files for the bank import workflow. The whole batch takes about ten minutes and avoids a manual data entry exercise that would otherwise consume most of a working day.

Pro tips

Get better results with these expert suggestions:

RC4-40 PDFs are extremely weak and may be opened by many tools

PDFs encrypted with 40 bit RC4 covering PDF 1.1 through 1.3 have effectively no security against modern hardware. The short key length means brute force tools running on a single laptop can crack the password in seconds by exhaustive key search rather than even needing to guess the password itself. If you are creating new encrypted PDFs today, use AES 256 with a strong password of at least sixteen characters mixing letters, digits, and symbols to reach a key space that cannot be brute forced economically with current technology.

AES-256 Revision 6 uses UTF-8 passwords, not ASCII

PDF 2.0's AES 256 Revision 6 accepts Unicode passwords through UTF 8 encoding rather than being limited to the ASCII subset that earlier revisions effectively constrained. If your PDF was created with a non ASCII password including accented characters from European languages, non Latin scripts, or symbol characters, enter the password in UTF 8 encoding which most modern keyboards produce by default. ASCII only passwords work identically across all revisions because ASCII is a subset of UTF 8 with matching byte values for the basic character range.

The /U and /O entries in the encryption dictionary store hashed password verifiers

These entries do not store the actual password values, only derived hashes used by the reader to verify that the correct password was entered before attempting to use it for content decryption. This design means that the password itself cannot be extracted from an encrypted PDF by inspecting its structure with a hex editor or PDF parser, it must be either known by the user, guessed correctly, or recovered through a brute force search against the stored hash. The hash design prevents trivial password disclosure.

PDF encryption does not encrypt the file structure, only content streams

Metadata fields such as the document title, author, subject, keywords, and creation date may remain unencrypted even in a password protected PDF, because the specification allows certain metadata to remain accessible to search and indexing tools that need to catalogue files without prompting the user for passwords. Only content streams including page content, embedded files, and form data are encrypted by default. If you need to hide metadata as well, configure the PDF generator to include metadata under the encryption umbrella when creating the file.

FAQ

Frequently asked questions

To check in Adobe Acrobat, open File then Properties then Security and look at the Security Method and Details section, which lists the encryption algorithm whether RC4 or AES along with the key length and the security handler revision number. Alternatively, open the PDF in a hex editor or text editor that handles binary files and look at the /Filter, /V for algorithm version, /R for revision, and /Length entries inside the encryption dictionary referenced from the trailer to identify the exact algorithm in use. The PDF specification documents the meaning of each value combination clearly.

AES 128 uses a 128 bit key and was introduced in PDF 1.6 corresponding to Acrobat 7 in 2005. AES 256 uses a 256 bit key and was introduced in PDF 1.7 Extension Level 3 corresponding to Acrobat 9 in 2008, with the key derivation reworked in PDF 2.0 Revision 6. AES 256 provides a dramatically larger key space than AES 128 making brute force attacks against the key itself computationally infeasible with any foreseeable hardware. Both are secure against all known practical attacks when combined with a strong password that has sufficient entropy in its own right.

RC4 40 bit covering PDF 1.1 through 1.3 has not been secure for many years and can be brute forced in seconds on a modern laptop without needing to guess the password at all. RC4 128 bit covering PDF 1.4 and 1.5 is weak by current standards because the RC4 cipher itself has known cryptographic vulnerabilities including biased outputs that are independent of key length, and RC4 is deprecated in most security standards including TLS where it was banned. PDFs that need to remain secure today should be re encrypted using AES 256 with a strong password. If you are decrypting an RC4 PDF you legitimately own, FixTools handles both variants correctly.

Yes. The PDF specification defines both a user password used for opening the document and an owner password used for setting permissions. Either password can be used to derive the document encryption key in most PDF security revisions covering R2 through R5, because both passwords compute to the same intermediate key in those revisions. Entering the owner password in FixTools will decrypt the file the same way the user password would and produces equivalent output. PDF 2.0 Revision 6 uses separate key derivation paths for user and owner passwords with different stored hashes, but FixTools detects which password was provided and follows the correct path.

MD5 was considered secure for the cryptographic uses it was applied to when PDF encryption Revisions 2 and 3 were standardised in the late 1990s and early 2000s, predating the public discovery of MD5 collision attacks. The MD5 digest in these PDF revisions is used not for authentication of messages but for key derivation and key material mixing through repeated hashing. While MD5 is now broken for collision resistance in adversarial contexts, its use in this specific key derivation context does not directly expose the encryption to known collision attacks. However, the combination of MD5 derivation with 40 bit or 128 bit RC4 keys still makes the older PDF encryption variants weak overall and unsuitable for protecting sensitive content today.

The encryption dictionary referenced by the /Encrypt entry in the PDF trailer contains several fields that together describe how the file is protected. The /Filter entry is usually /Standard for password based protection. /V and /R hold the algorithm and revision numbers respectively. /Length specifies the key length in bits. /P holds the permission flags as a 32 bit signed integer with specific bits assigned to specific operations. /O is the owner password verifier hash. /U is the user password verifier hash. For AES 256 Revision 6 PDFs, additional /OE, /UE, and /Perms entries hold encrypted key material and protected permissions. The actual document encryption key is derived from these stored values combined with the user supplied password through the revision specific key derivation function.

FixTools writes the decrypted content into an output PDF that preserves the original version header from the input file. The output file is structured as a standard PDF without an encryption dictionary, but the underlying PDF version such as 1.6, 1.7, or 2.0 declared in the header is retained so that downstream tools know which version of the specification to expect when parsing the file. Some PDF tools may update the version header as part of their normal output pipeline to whichever version their writer targets, but this is a cosmetic change in the header bytes and does not affect compatibility with readers.

PDF 2.0 Revision 6 introduced a new key derivation process that uses SHA 256 with random salts per password slot, separate user and owner key derivation paths, UTF 8 password normalisation through a specified preparation algorithm, and an additional validation key check before content decryption. Older PDF tools built against the pre 2.0 specification may not implement Revision 6 correctly or at all, and will silently fail or return an incorrect password error when given a Revision 6 file. FixTools implements the full Revision 6 specification including the corrected algorithm published as Errata to the original spec. If another tool fails on your PDF, a Revision 6 incompatibility is the most likely cause.

Yes. PDFs protected by proprietary Digital Rights Management systems that operate outside the standard PDF encryption specification cannot be decrypted by any tool that implements only the standard. Common examples include Adobe Digital Editions DRM used for commercial ebooks, LockLizard which adds its own protection layer, and Microsoft Information Protection labels which apply Azure Rights Management. These systems require the original rights management server to authorise each access and do not expose a single password that could decrypt the file offline. FixTools and other standard tools cover the full standard but stop at the boundary of proprietary DRM.

Decryption performance scales with the size of the encrypted content streams and the speed of the device's CPU and memory. For a typical 5 MB PDF, decryption completes in under a second on a current laptop. For a 50 MB document with embedded images, expect a few seconds. For very large files above 200 MB, decryption may take ten to thirty seconds depending on memory bandwidth and whether your CPU has hardware AES acceleration through AES NI instructions on Intel and AMD chips or the equivalent on ARM. The Web Crypto API uses these accelerated instructions transparently when available.