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 qpdf 11.0.0 (Apache-2.0), compiled to WebAssembly by the @jspawn/qpdf-wasm package. It is the command-line tool itself, not a reimplementation, 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 the non-threaded one, which matters more than it sounds: it needs no shared memory, so the page needs no cross-origin isolation headers, so nothing else on the site has to change to accommodate it. Each job starts a fresh copy of the module, because qpdf exits once and leaves its runtime spent; measured on a 3 KB AES-256 file, loading and decrypting took about 40 ms in the browser and 23 ms in Node.
qpdf reports its outcome as an exit status 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 pdf-lib, an unrelated PDF library, has to parse it with no password at all. Finally pdf.js - the reader behind the PDF to Word tool - opens the copy without a password and 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 normalisation
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 readers and writers skip that, and so does qpdf 11.0.0, 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 qpdf with "invalid password" (exit 2) and unlocks cleanly (exit 0) once the normalisation 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.