What "unlocking" a PDF actually does: two passwords, one key, and the limits of the word
"This PDF is locked" describes at least three different situations. The file asks for a password before it will show anything. The file opens fine but refuses to print, or to let you copy text, or to be edited. Or the file opens, prints and copies, but a tool such as a merger or a watermarker says it cannot modify it. All three are called "locked"; all three are "unlocked" by different means; and one of them cannot be unlocked at all without the password. Understanding why requires knowing how PDF encryption actually works, which is simpler than it sounds.
One key, two passwords
When a PDF is encrypted, its contents — page streams, text, images, metadata — are encrypted with a single symmetric key, today an AES-256 key, generated randomly when the document is protected. The key is never stored in the file. Instead, the file stores two things derived from it: a version of the key locked with the user password (the "open" password) and a version locked with the owner password (the "permissions" password). Supply either password, and the viewer recovers the same key and decrypts the same content. That is the whole mechanism. The two passwords are two doors to one room.
Alongside the key material, the file stores a permissions field: a set of flags saying whether printing, copying, editing, annotating and form filling are allowed. A viewer that opened the document with the user password is expected to honour those flags. A viewer that opened it with the owner password is allowed to ignore them and to change them. This is where the trouble starts.
Why permissions are so easy to strip
Here is the design flaw, present since PDF 1.1 and still true in PDF 2.0. When a document has an owner password but the user password is empty, any viewer can open it: it derives the key from the empty user password, decrypts everything, and then reads the permission flags and politely declines to print. The decision to obey the flags is made by the viewer, in software, after it already holds the fully decrypted content. Nothing cryptographic prevents a viewer from simply not obeying — and many tools, open-source and commercial, do not.
This is why "remove restrictions from a PDF" tools exist and work instantly, and why they are not doing anything clever. They open the file with the empty user password, obtain the key, and write the content back out without the encryption dictionary. No password is guessed and nothing is broken; the restrictions were only ever a request. Adobe's own specification acknowledges this: the permissions are described as being enforced by "conforming readers", which is to say, by convention.
The practical conclusion for anyone protecting a document: permission restrictions communicate intent and stop the honest majority from casually copying a paragraph. They do not stop anyone who wants to, and they should never be relied on for confidentiality. If content must not be extractable, do not distribute the PDF, or distribute it rasterised, and accept the trade-offs of that.
Why an open password is a different matter
When the user password is set — the document asks for it before showing anything — the key is only recoverable from that password. With modern encryption (AES-256, per PDF 2.0, which is what our protect tool applies), the derivation involves hashing the password with a random salt many times, and the resulting key cannot be reversed. A tool that does not have the password has exactly two options: try passwords one after another, or give up.
Trying passwords is what "PDF password recovery" software does. Against a short or common password — a birthday, a word from a dictionary, "1234" — it succeeds, because the candidate list is small. Against a long random one it does not, because the number of candidates exceeds what any hardware can try in a useful time. Sites that claim to "unlock any PDF without the password" are either doing exactly this dictionary attack on your uploaded file (and, note, now have your file) or are handling the easy case above — an owner-only password — and describing it grandly.
Older PDFs are weaker. Files encrypted with 40-bit RC4 (PDF 1.1–1.3, common in the early 2000s) have such a small key space that the key itself, not the password, can be found by brute force in hours on ordinary hardware. 128-bit RC4 and AES-128 (PDF 1.4–1.6) are strong enough that the password is the only realistic attack. If you receive a very old protected document and have a legitimate need to open it, that history is worth knowing; for anything produced in the last fifteen years, only the password gets you in.
What our unlock tool does, precisely
You supply the file and a password. The tool hands both to pdfcpu, running as WebAssembly in your browser, which tries the password as the user password and as the owner password — because either one decrypts the document and we cannot know which you hold. If one works, the key is derived, the content is decrypted and the document is rewritten with no encryption dictionary and no permission flags: a plain PDF that opens, prints and edits anywhere. If neither works, you get an error and no output. There is no dictionary, no retry loop and no server: the password and the file stay in the tab.
One consequence of this design: the tool asks for a password and will not run without one, so for a file that has only an owner password (the easy case) you need to know that password. It does not try the empty user password on your behalf — a deliberate choice, since "remove the restrictions from a file I was sent" is a decision we would rather you make explicitly than have a tool make silently. If you hold the owner password, it works exactly like any other.
The third kind of "locked"
Sometimes a file opens and prints but a tool refuses to merge, watermark or number it. That is usually not encryption at all but one of two things: a digital signature, which locks the signed bytes so that modifying them would invalidate the signature and which editors respect by refusing; or a certified document with "no changes allowed" set by the signer. Neither has a password to remove. To modify the document, you accept losing the signature: print to PDF, or export the pages as images and rebuild, both of which produce an unsigned copy. Whether you should do that depends on why the document was signed.
Where the line is
Removing an owner password from a PDF you were sent so you can print it is unremarkable and, in most jurisdictions, entirely lawful — you are entitled to use a document you legitimately hold. Removing a user password you know, from your own document, is equally unremarkable. Attempting to recover a password you were never given, on a document that was protected specifically to keep you out, is the case the law and basic ethics treat differently, and it is also the case no honest tool can help with. Our tool cannot tell which situation you are in; it can only decrypt what the password you hold unlocks. That responsibility stays with you.