How to unlock a password-protected PDF (when you know the password)

The scope: PDFs you are entitled to unlock

The most important caveat up front. This tool is for PDFs whose password you legitimately know, or PDFs that only carry an owner-permission restriction with no open password at all. It is not a brute-force tool, and it is not intended for unlocking documents a counterparty sent you under a confidentiality agreement. If the sender chose to protect the file, removing that protection without permission is not the use case here.

With that frame in place, the situations where unlocking is genuinely needed come up more often than you might expect. You set a password on an archive years ago and can no longer remember it confidently for everyday access. Recipients keep reporting that they cannot open the file or upload it to their internal system, so you want to keep an unprotected internal copy. A scanner’s batch setting silently applied an owner password (no printing, no editing, no copy/paste) to every PDF you produce, blocking OCR pipelines and expense systems downstream. Those are exactly the cases pdf-unlock is built for.

Removing the protection in the browser

Open pdf-unlock and drop one or more PDFs onto the page. The tool checks the encryption status on load, then asks for a password — type it in (or leave it blank for the owner-only case below) and press “Unlock”. The result is a decrypted PDF you can download immediately.

PDFs that carry only an owner password — the kind that open without prompting but block printing, editing, or copy/paste — can be unlocked with an empty password field. That is not a security bypass; it is the documented behaviour of qpdf because the PDF specification lets the decryption key be derived from the encryption dictionary when no user password is set, and the owner password only controls permission flags. PDFs that prompt for a password when opened (a user password) need the correct value; an incorrect password returns an “invalid password” error and leaves the file untouched.

After a successful unlock you get a PDF with all text, fonts, images, layout, and bookmarks preserved — only the encryption flag is gone. The file size stays roughly the same, possibly a few kilobytes smaller because the encryption overhead is removed. Multiple PDFs can be processed at once with individual or ZIP downloads, and reloading the tab discards both the inputs and the password from memory.

What qpdf-wasm is doing under the hood

The engine is qpdf compiled to WebAssembly. qpdf is a long-established native C++ tool for PDF structure manipulation (linearize, decrypt, repair) and we ship it as /public/qpdf/qpdf.js plus qpdf.wasm built via Emscripten. The browser loads the script, instantiates the wasm module, writes the input PDF into Emscripten’s virtual filesystem (qpdf.FS.writeFile), then runs qpdf.callMain(["--password=...", "--decrypt", "in.pdf", "out.pdf"]). The decrypted output is read back out of qpdf.FS and wrapped in a Blob for download.

PDF encryption uses one of AES-128, AES-256, or the older RC4 cipher; modern PDFs (1.7+) default to AES-256. The password is not used as the key directly — it is mixed with the document’s salt to derive the decryption key, and qpdf performs that derivation, decryption, and rewrite in one command. The owner-password-only case unlocks with an empty password because the PDF spec (ISO 32000) lets the decryption key be derived from the encryption dictionary in that path; the owner password only carries permission flags. Before running qpdf the tool runs a cheap pdf-lib probe to confirm an encryption flag is actually set, so unprotected PDFs are rejected early instead of being passed pointlessly through qpdf.

Why this is a workflow worth keeping in your tab

Searching for “PDF password remove” brings up plenty of services that ask you to upload both the encrypted PDF and the password to their backend. That combination — ciphertext plus the matching key on the same form post — is unusually bad as a data flow. If their logs ever leak, the password becomes a working key against every other file you protected with the same password (and password reuse is the norm). An encrypted PDF on its own costs an attacker meaningful effort; with the cleartext password attached, the cost is zero.

Inside the browser, neither the password nor the PDF leaves the tab. The WebAssembly runtime fetches /qpdf/qpdf.js and qpdf.wasm once on first use, and beyond that no request carries file content. The source on GitHub shows the qpdf.callMain call site and the fact that both input and output stay in Emscripten’s in-memory qpdf.FS. Being able to remove the protection without leaving an audit trail on a third party is meaningful for sensitive PDFs — and even for routine owner-password removal of files tied to your name or your employer, the marginal cost of doing it in-tab is low enough to make it a default.