Remove PDF password

Choose a PDF you can already open, type the password it asks for, and get back a copy that opens without one. The decryption runs inside this browser tab, so the document and the password that unlocks it both stay on your machine. There is no step in the process where either one is sent anywhere.

Two locks live in the same file, and only one of them ever asks you anything

A protected PDF can be carrying either of two completely different things, and the word password gets used for both. The first is the open password, sometimes called the document or user password. Without it every page stays ciphertext and no reader on earth can show you anything. The second is the owner password, sometimes called the permissions or master password, and it does not gate opening at all. It gates the flags that say whether printing, copying text or filling in forms is allowed.

The confusing part is that a file with only an owner password is still fully encrypted. The standard security handler simply records the empty string as the open password, which is why every reader decrypts it silently and then decides, on its own honour, whether to grey out the print button. Nothing was bypassed when it opened without asking you. That was the state the file was published in.

This page tells you which of the two you are holding the moment you choose the file, before you press anything and before you type anything. If it says the document opens without a password, leaving the box empty is the correct answer rather than a shortcut.

Permission flags are a request, not a wall

The permissions live in a single integer in the encryption dictionary, one bit per capability. A reader looks at that integer and decides how to behave. There is no cryptographic enforcement behind it: the page content is decrypted either way, and a reader that ignored the integer entirely would still render the document perfectly. Several of them do.

That is worth saying out loud, because it changes what removing an owner password actually means. It is not breaking into anything. It is ending an arrangement in which every well-behaved reader was asked to pretend it could not do something it was demonstrably able to do. The open password is real cryptography and is treated as such here. The permissions integer never was.

It also explains a very common frustration. Someone tries to copy a paragraph out of a report, gets nothing, assumes the file is damaged, and downloads it three more times. The file was fine. A flag was set, possibly years ago, possibly by a system nobody at that organisation still maintains.

What the file quietly remembers about your password

To check a password without storing it, the encryption dictionary keeps derived values: two strings called O and U, plus two more called OE and UE once AES-256 is in play. They are the output of a one-way derivation, so they are not the password. They are, however, exactly the material a guessing program needs. Feed it a candidate, run the same derivation, compare. No document required, no rate limit, no server to slow anything down.

Most tools that call themselves unlockers never remove those values. They stop referencing the encryption dictionary from the trailer, which is enough to make the file open, and leave the dictionary itself sitting in the document as an unreferenced object. The result opens without a password and still carries a complete offline verifier for the password you used, permanently, to everyone who ever receives that copy. Given how many people reuse one password across a decade of statements from the same sender, that is not a small leftover.

So this page deletes it. The security handler dictionary goes, any surviving reference to it goes, and so does one thing that is easy to miss: the stale cross-reference object from the original file. Some libraries cannot parse that object and therefore copy it across byte for byte, carrying its own pointer to the encryption dictionary with it. That last case is also why a test like does the output still contain the text slash-Encrypt is a bad check rather than a good one. The real check here is different in kind: the finished copy is re-opened by a PDF library that contains no decryption code at all. If it were still encrypted, that step would fail instead of pass.

Four generations of PDF encryption, and why the oldest ones still turn up

The format has revised its security handler four times, and files from all four eras are still in circulation. Revision 2 used RC4 with a 40-bit key, a ceiling set by 1990s export rules on cryptography rather than by anyone technical judgement. Revision 3 kept RC4 and raised the key to 128 bits. Revision 4 introduced AES-128. Revisions 5 and 6 moved to AES-256, which is what current office software writes by default.

Old revisions persist because the software that emits statements, invoices and scanned archives tends to be the software an organisation least wants to touch. A billing system built around a 2004 library will still be producing RC4 documents this month, and a multifunction scanner in a meeting room will happily encrypt to whatever its firmware learned years ago.

All four are handled here, and after a successful unlock the page names the one it found. That is not decoration. Learning that a document somebody sent you is protected with 40-bit RC4 is genuinely useful information about how much protection it ever had.

Typing a document password into a website is a different bet from uploading a file

Every no-upload argument on this site applies here, and then there is one that applies only here. When you upload a protected PDF to a conversion site and type its password into the same form, you have handed one machine the ciphertext and the key together, in the same request, seconds apart. Whatever protection the encryption was providing against that machine is gone by definition rather than by accident.

It is also the kind of secret that travels further than intended. A password submitted as a form field can end up in an access log, an error report or a crash dump without anybody deciding that it should. And it is rarely a throwaway string: the same one usually opens twelve months of statements from the same sender.

Here the password goes into a variable in this tab, is handed to decryption code that was compiled into the page you already downloaded, and stops existing when you close the tab. The general recipe for satisfying yourself that nothing leaves is written up on the tools that never upload page rather than repeated here. What is worth adding is the asymmetry. For every other tool on this site, verifying no-upload means checking that a file you already have did not leave. On this page it also means checking that a secret you just typed did not leave, and that is the more valuable of the two guarantees.

What this page cannot do, stated without hedging

It cannot open a document whose password you do not have. That is not a limit we could lift with more effort. Against AES-256 and a password that is not in a word list, the only known route is to try candidates until one works, which is what dedicated offline recovery software does, on hardware chosen for it, over hours or weeks. A web page is the wrong shape for that even before anyone asks whether it ought to exist.

Guessing is not implemented here, and that is a decision rather than an oversight. A page that tries candidate passwords against arbitrary documents is a page whose most enthusiastic users are, by construction, not the people those documents belong to. The line drawn here is that you already hold the password, or the document already opens without one.

Two further things are out of reach for reasons that have nothing to do with policy. Rights-management systems layered on top of PDF by other vendors are not the standard security handler, so none of this touches them. And a document that will not open is a document nobody can characterise for you: if a file fails here, this page cannot tell you whether the password is wrong, whether the file is damaged, or whether it was never really a PDF.

What changes in the copy you get back, and what does not

Page structure is preserved rather than re-rendered. Text stays selectable text, vector artwork stays vector, embedded fonts stay embedded, and no image is decoded and re-encoded along the way. There is no generation loss, because nothing is regenerated.

Two things do change, both unavoidably. The permission flags disappear along with the dictionary that held them, which is the entire point. And any digital signature on the document stops validating, because a signature is a statement about one exact sequence of bytes and this operation produces a different sequence. That is a signature working correctly rather than a defect: a signature that survived the file being rewritten would be worth nothing. If the signature is the reason the document matters, keep the original and treat the unlocked copy as a working file.

File size usually moves a little in one direction or the other. Encrypted streams do not compress, so removing encryption can shrink a file, while the rewrite may lay objects out less tightly than the original producer did.

Where a password you are entitled to usually lives

Passwords on documents that arrive automatically are almost never chosen one at a time. They come from a rule the sender applies to everybody, and that rule is nearly always written down somewhere you can already reach: the covering email, the first page of the previous statement, the help section of the account portal, or the letter that announced the switch to paperless delivery.

Common shapes are the last four digits of an account or card number, a date of birth in a fixed format, part of a national identifier, or a postcode with the space taken out. When one attempt fails it is usually the format that is wrong rather than the value, so try the same number with and without separators before concluding anything.

If a person sent the file rather than a system, the person is the answer, and asking them is both faster and more reliable than anything a piece of software can offer you.