Does this tool work with scanned PDFs?

This tool works with all standard PDF files. For scanned documents (image-only PDFs), text extraction features may be limited since the content is stored as images rather than selectable text.

Are my PDF files uploaded to a server?

No. All PDF processing happens entirely in your browser. Your documents never leave your device, which makes this tool safe for sensitive or confidential files.

Can I use this on password-protected PDFs?

Password-protected PDFs need to be unlocked first. If you know the password, you can use our PDF Unlock tool to remove the protection before using this tool.

Free PDF Unlock Online

Remove passwords from encrypted PDFs in seconds. Instant processing, no sign-up required.

Your files never leave your device

Drop your PDF here or click to browse

Password-protected PDFs only · up to 100 MB

Password

How It Works

Upload your password-protected PDF using the drop zone above.
Enter the PDF's password in the password field.
Click "Unlock PDF" to decrypt and remove the password.
Download your unlocked PDF instantly · processed entirely in your browser.

Why Unlock PDFs?

Password-protected PDFs can be inconvenient if you forget the password, receive a locked file from a colleague, or need to process files in bulk. Unlocking removes the password restriction so you can open the PDF freely, share it without password sharing, or use it in automated workflows. This is completely safe and legal when you have authorization to access the PDF.

Security & Privacy

100% Client-Side · All processing happens in your browser. No data is uploaded to any server.
No Logs · Your PDFs and passwords are never stored, logged, or tracked.
Secure Processing · Decryption runs via qpdf (the reference PDF toolkit) compiled to WebAssembly. 1.3 MB one-time download, cached after.
Your Control · You control when files are processed and can clear them anytime.

Frequently Asked Questions

How long does unlocking take?

Unlocking is nearly instant. Most PDFs process in under a second. Larger files may take a few seconds depending on your device's processing power.

Is there a file size limit?

PDFs can be up to 100 MB. Since processing happens locally in your browser, very large files may take longer depending on your device.

Is this legal?

Yes, unlocking a PDF you own or have permission to access is completely legal. This tool is intended for PDFs you created or have authorization to modify. Never unlock PDFs belonging to others without their permission.

Does the unlocked PDF look different?

No. The unlocked PDF is identical to the original except the password protection is removed. Content, layout, images, and formatting remain exactly the same.

What if I forget the password?

Unfortunately, if the PDF is encrypted with a strong password you don't know, there's no way to unlock it. Password-protected PDFs use encryption that cannot be bypassed without the correct password.

What "PDF unlock" actually means

The phrase "PDF unlock" covers two genuinely different operations that the PDF specification treats separately, although end users rarely distinguish them. The first is removing an open password (also called a user password or document-open password). A PDF with an open password is encrypted at the storage level: the page content, font resources, and embedded images are stored as ciphertext on disk, and no PDF reader can render the page without first decrypting the streams using a key derived from the password. Unlocking this kind of PDF requires the correct password. There is no way around the mathematics; the encryption is real, and the key is derived from the password through a one-way function.

The second is removing a permissions password (also called an owner password or restriction password). A PDF with a permissions password is technically still encrypted, but the open-document operation does not need the password: any PDF reader can render the file. What the permissions password protects is the set of operations the reader is permitted to perform, encoded in a 32-bit field called P. Specific bits in P govern printing, copying text, modifying content, filling forms, extracting content for accessibility, and so on. Removing a permissions password means rewriting the document with all P-bits set to 1 and discarding the encryption layer. No password input is required for that case. This tool handles both: supply the open password to remove both layers, or leave the field blank if the PDF only has a permissions password.

How this tool works

This tool uses qpdf, a structural PDF toolkit written in C++ by Jay Berkenbilt and maintained as open source since 2008. qpdf is the reference implementation of PDF structural operations and is used as a building block by most other open-source PDF utilities, including Ghostscript, PDFtk, and the standard Linux command-line PDF tools. A number of server-side commercial PDF services use qpdf under the hood as well, sometimes without acknowledging it. qpdf implements the standard security handler (Filter /Standard) defined in the PDF specification, which covers every password-based encryption scheme from RC4 40-bit (PDF 1.1, 1994) through AES-256 V=5/R=6 (PDF 2.0, current).

qpdf is compiled to WebAssembly through Emscripten, producing a single roughly 1.3 megabyte module that runs inside this browser tab. The module is downloaded once on first visit and cached by the browser; subsequent visits load instantly. When you select a PDF, the browser File API hands the bytes directly to the qpdf WASM module running in the JavaScript engine. The module parses the encryption dictionary, prompts for the password if needed, decrypts every encrypted stream and string, removes the Encrypt entry from the trailer, rewrites the cross-reference table, and returns the unlocked bytes back to the page as a Blob. No network request fires during the unlock. You can verify it: open the browser developer tools to the Network tab before clicking Unlock, run the operation, and observe that nothing leaves your machine.

PDF encryption, 1994 to 2026

PDF encryption has been a moving target since the format was introduced in 1993. Each major specification revision added a new algorithm or fixed a key-derivation flaw in the previous one. The algorithm in use determines what the unlock operation is doing under the hood; qpdf recognises all of them and dispatches to the right implementation. The encryption dictionary's V field (algorithm version, 1 to 5) and R field (revision of the standard handler, 2 to 6) identify the scheme.

PDF 1.1 (1994), RC4 40-bit, V=1, R=2. The 40-bit limit was set by US export-control law at the time; longer keys could not legally be exported as "munitions." A 40-bit key has 2^40 (about one trillion) possible values, which is exhaustible on commodity hardware in seconds in 2026. PDFs still encrypted at this level offer no real protection.
PDF 1.4 (2001), RC4 128-bit, V=2, R=3. The export restriction lifted in 2000; Adobe extended the key to 128 bits. A 128-bit key is well beyond brute-force reach, so the weakness, when there is one, is in the user-chosen password rather than the algorithm itself.
PDF 1.6 (2004), AES-128 CBC, V=4, R=4. Added in response to growing concern about RC4's keystream biases (the Mantin-Shamir 2001 result, then Schneier's 2013 wake-up call that pushed RC4 out of widespread use). AES-128 is the same algorithm the US government uses to protect classified data up to the Secret level.
PDF 1.7 Extension Level 3 (2008), AES-256 first revision, V=5, R=5. Introduced by Adobe in Acrobat 9. Within a year, researchers found a key-derivation flaw that made it weaker than AES-128 in practice. Adobe published a fix.
PDF 1.7 Extension Level 8 (2010), AES-256 corrected, V=5, R=6. The current state of the art. Uses PBKDF2-style key derivation with SASLprep Unicode normalisation, so passwords work consistently across input methods and locales. This is what Acrobat X and later, and every modern PDF tool that exposes "AES-256 encryption," produces.
PDF 2.0 (2017), V=5/R=6 formalised. ISO 32000-2 adopts V=5/R=6 AES-256 as the recommended algorithm and deprecates RC4 entirely. The encryption story stabilises here; subsequent PDF features have not required changes to the encryption layer.

User password versus owner password

The PDF specification calls these the "user password" and the "owner password." Most consumer-facing tools call them the "open password" and the "permissions password," which is more descriptive. A user password is the one you type to open the file in a reader. The document's content streams are encrypted with a key derived from this password, so the file is unreadable without it. The encryption is real: PDFs with strong user passwords resist any known attack short of exhaustive search through the password keyspace, which is computationally infeasible for passwords longer than about ten random characters.

An owner password is different. The document is still encrypted, but the open-document operation succeeds without any password input; any PDF reader can render the file. What the owner password protects is the set of operations the reader is permitted to perform, encoded in the 32-bit P field of the encryption dictionary. Bits in P govern printing, copying text, modifying content, filling forms, extracting for accessibility, and assembling pages. Honourable PDF readers respect these bits even when the user lacks the owner password; less honourable ones ignore them. The unlock operation removes both layers: it decrypts the streams and discards the P field, producing an output PDF with no restrictions of any kind.

Real-world workflows that drive PDF unlock

Forgotten password on your own document. You set a password on a PDF months or years ago, archived it somewhere, and now need to access the content. If you remember the password, this tool removes it in seconds and you keep a clean copy for future use. If you do not remember, no online tool can recover it without exhaustive search; the realistic options are desktop cracking with hashcat or John the Ripper, and accepting that strong passwords are designed to be unrecoverable.
Received a locked file with the password sent separately. You can open the PDF, but every time you want to edit, sign, or include it in a workflow, the password prompt appears. Removing the password once produces a working copy that integrates cleanly with every downstream tool. Particularly common for legal contracts, bank statements, and tax returns delivered through secure-email systems.
Batch processing and automation. A backend pipeline that handles PDF input cannot easily prompt for a password. The standard workflow is to unlock the PDFs as a one-time preprocessing step, store the unlocked copies in a private location, and feed the pipeline from there. Common in document-intake systems, archival projects, and document-search index builds.
E-signature workflows. Most e-signature platforms (DocuSign, Adobe Sign, HelloSign, PandaDoc) reject password-protected PDFs at upload because they cannot prompt the recipient for a password. The fix is to unlock the document first, then upload it for signing. Many "why won't DocuSign accept my PDF?" support tickets resolve here.
Accessibility. Screen readers cannot always traverse permissions-restricted PDFs, even when the extract-for-accessibility bit (P bit 10) is set, because some readers gate accessibility behind the absence of a permissions password entirely. Removing the permissions layer produces a document that every accessibility tool can read.
Archival migration. Long-term document archives often discover that the password used to encrypt some documents has been lost. Where organisational policy permits, unlocking the recoverable documents (those where the password is known or can be reconstructed) and re-protecting them with current organisational credentials is a standard part of archive maintenance and format migration.

Common pitfalls and what they mean

"Incorrect password" when you are sure the password is right. Two common causes. First, the keyboard layout that produced the password originally differs from the one now in use, so a character that looks identical on screen is actually different (a non-breaking space typed on macOS versus a regular space on Windows is the classic). Second, the PDF was encrypted with an algorithm older than V=5 and the password contains non-Latin-1 characters, which were encoded inconsistently in older revisions. Retry with each plausible character variant.
The PDF opens without a password in your reader but this tool asks for one. The PDF has a permissions password (owner password) but no open password (user password). Leave the password field blank and run the unlock; the tool removes the permissions layer without any password input. The "password" prompt is always shown so the workflow handles both cases uniformly.
Reader asks for a password but this tool reports the file is not encrypted. The encryption is non-standard: most often a Filter other than /Standard, such as Adobe LiveCycle, FileOpen, or a custom DRM scheme. These are not handled by qpdf or any other open-source PDF library and require specialised software from the DRM vendor. Certificate-based (public-key) encryption is a separate scheme and also not supported here.
The digital signature becomes invalid after unlock. By design. Unlocking rewrites the document, which by definition invalidates any cryptographic signature attached to the original byte sequence. Signed PDFs should be unlocked only when the signature is no longer needed, or re-signed afterwards using whatever signing tool the workflow uses.
The unlocked PDF has missing or scrambled text. Three plausible causes: the encryption was not applied uniformly to the document (rare but possible with hand-built PDFs), the file is partly corrupted, or the source PDF contains non-standard structures that qpdf is conservatively skipping. Try Adobe Acrobat for the file, or a desktop PDF repair tool, before assuming the document is lost.
Reader still shows "Secured" after unlock. A few readers cache the security dictionary values from when they first opened the document, and do not refresh the cache after a save. Close the unlocked file in the reader, then re-open it; the security panel should show "No security." If it does not, the file in your reader is still pointing at the locked original; reload the unlocked output explicitly.

Browser-only versus cloud unlock

The cloud PDF-unlock services that fill the top of search results (Smallpdf, ILovePDF, PDF24 web, Adobe Acrobat Online, Sejda) all upload your password-protected PDF to their servers along with your password, decrypt the file server-side, and serve the unlocked copy as a download. The privacy implications differ from a normal file upload in two important ways. First, the password itself transits the operator's network and exists briefly in operator logs and memory. Second, the operator now holds both the encrypted file and the decryption key, so even users comfortable with "they have my encrypted file" implicitly accept "they have my decrypted file too" with cloud unlock. The major operators publish privacy policies committing to deletion within hours and TLS in transit, and they have strong commercial reasons to comply, but "deletion within hours" is not "never seen."

This tool does not upload the file or the password. The qpdf WASM module runs in your browser tab, receives the file bytes through the File API and the password through a standard HTML input, and returns the decrypted bytes back to the same tab. You can prove it: open the browser developer tools to the Network tab before clicking Unlock, run the operation, and observe that no requests are made with your file or password content. The trade-off is feature scope. Cloud services often offer "password recovery" alongside "password removal," running distributed brute-force or dictionary attacks on server farms to guess unknown passwords. Browser-side cracking is many orders of magnitude slower than GPU-accelerated server-side cracking, so password recovery is not in scope for a browser tool. If you do not know the password and the PDF was encrypted with a strong algorithm, the realistic options are desktop cracking with hashcat (formats 10500, 10600, 10700) or John the Ripper's pdf2john extractor, and accepting that strong passwords are designed to be unrecoverable.