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.
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
Free with no registration
- Cost
- Free tier
- Sign-up
- Not required
- Processing
- Tool-specific
- Privacy
- Clearly disclosed
Add this Unlock PDF to your website
Drop the Unlock PDF into a blog post, product docs, intranet, or school portal with one iframe. Processing, privacy, and usage limits are the same as on the full tool page.
- One copy-ready line of HTML
- Responsive — adapts to any container width
- No API credentials are placed in the snippet
Embed code
<iframe
src="https://www.fixtools.io/pdf/unlock-pdf?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Unlock PDF by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
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.
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.
Frequently asked questions
Ready to get started?
Open Unlock PDF to review its free limits and processing method.
Open Unlock PDF →Free tier · No account needed · Transparent limits