Unlock PDF

What a password-protected PDF really stores

An encrypted PDF keeps an /Encrypt dictionary in its trailer describing how the file was protected: /Filter /Standard for the ordinary password case, a 40, 128 or 256-bit key, and a revision number saying which rules were used - 2 and 3 for RC4, 4 for AES-128, 6 for AES-256. Two keys are derived from the two passwords, and every string and stream is encrypted with a key built from them.

That is why knowing the password is all it takes. There is nothing to break and no brute force involved: the file carries everything needed to recompute the key, and the password is the missing ingredient. It is also why the tool cannot help with a file whose password you do not have, and why a certificate-protected file is refused outright - there the key is not derived from a password at all, so no password would work.

The copy that comes out has no encryption left in it, which is the only honest meaning of unlocked: the restrictions an owner password carried - no printing, no copying, no editing - go away with it, because a PDF without encryption has nowhere to keep them.

The unlocker itself, and why the page still works normally

The decryption is done by a full-strength PDF decryption engine that runs inside this browser tab. It is the real decryption tool itself, not a simplified copy, and it is fetched by this page as an asset of this site - about 1.2 MB raw, roughly 340 KB over the wire - the first time you unlock something.

This build is deliberately lightweight: it needs no special browser isolation, so nothing else on the site has to change to accommodate it. Each job starts a fresh copy of the engine, because a decryption run ends once and cannot be reused; measured on a 3 KB AES-256 file, loading and decrypting took about 40 ms in the browser and 23 ms in a command-line environment.

The engine reports its outcome as a status code rather than as something this page can read: 0 means clean, 3 means it repaired the file while warning about it, 2 means it refused. Only 0 is accepted. A file that could only be repaired by guessing - which is what a download that never finished looks like - is thrown away with an explanation instead of being passed on.

Three checks between the job and your download

First the copy must have no /Encrypt entry left, so it cannot ask for a password again. Then it has to open with no password at all in a second, independent PDF reader. Finally it has to report the same page count, the same first page size and the same first page text as the original did when it was read with your password.

Those readings are compared exactly, character for character, and a mismatch ends the job with the numbers that disagreed: "12 pages in the original against 11 in the copy", say, or "different text on the first page". No download appears in that case, because a file that opens but is not the same document is the one result worse than an error message. The result panel also names what the file used - AES-256, revision 6, or RC4-40, revision 2 - read from the file's own encryption dictionary.

The step most tools skip: password normalization

PDF 2.0 says a password must be prepared before the key is derived from it, with the SASLprep rules (NFKC plus a set of Unicode mappings). Many PDF readers and editors skip that, and so does the engine used here, which leaves a trap: the password that opens the file in your PDF reader can be refused by an unlocker that hands it over unchanged.

Measured on a sample built for exactly this: a file whose password is "a" but which is typed as U+00AA (the feminine ordinal, which NFKC folds to "a") is refused by that engine with "invalid password" (status 2) and unlocks cleanly (status 0) once the normalization runs first. This tool therefore tries what you typed, then its prepared form, and finally the empty password - a file can have no user password at all - and it tells you which of those worked and why.