How to add or remove a PDF password

PDF security is two separate things wearing the same name, and confusing them is why people are surprised by what tools can and cannot do. One is a user password, which is required to open the document at all: without it the file's contents are encrypted bytes and nothing can read them. The other is an owner password, sometimes called a permissions password, which leaves the document readable by anyone but marks it as not-to-be-printed, not-to-be-copied or not-to-be-edited. The first is real cryptography. The second is a request that readers are expected to honour. Knowing which one is on your file tells you immediately what is possible.

Adding a password that actually protects the file

When you set a user password, the document's streams — text, images, embedded fonts — are encrypted with a key derived from that password. Modern PDFs use AES with a 256-bit key, and the practical consequence is that a lost password means a lost document. There is no recovery, no reset link and no support desk; the only route back in is guessing, and against a decent passphrase that is not a route. Treat encrypting a PDF the way you would treat encrypting a disk: choose something you can reproduce, store it somewhere durable, and send it to the recipient over a different channel than the file itself. Emailing an encrypted attachment and the password in the same thread protects you from nothing except an honest mistake.

What owner passwords are worth

An owner password does not encrypt anything meaningfully. The document opens for everyone; the flags simply tell a compliant reader to grey out the print button or refuse a copy. Every serious PDF library can read and rewrite those flags, which is why tools that offer to remove printing restrictions work instantly and without asking you for anything. This is not a hack and it is not a defeat of encryption — the file was never protected in that sense. If your intent is genuinely to stop a document from being printed or extracted, a PDF is the wrong container, and you want a viewer-side rights system instead. If your intent is to signal that a form should not be edited, an owner password is a reasonable, honest signal and nothing more.

Old files, weak encryption

Not all encrypted PDFs are equally protected, and the difference is the year the file was made. The original scheme used RC4 with a forty-bit key, which was a defensible choice in the late nineteen-nineties and is now trivially breakable by any interested party with a laptop; a 128-bit RC4 revision followed, and only later did AES arrive, first at 128 and then at 256 bits. A document produced by an old scanner, an old accounting package or an office suite left on its legacy defaults may still be using the weakest of these, and its owner will reasonably believe it is protected because the reader asks for a password exactly the same way. If you are protecting something that matters, check what your software is actually applying rather than assuming, and if it offers a compatibility setting for older readers, understand that the compatibility being offered is with the weak algorithm. Re-encrypting an old archive with a current tool is a genuine security improvement even when the password stays the same, and it costs one pass over the file.

Removing a password you already know

The legitimate and by far the most common case is a file you own that arrives encrypted — a bank statement locked with your national ID number, a payslip locked with your birth date — that you need to store, search or forward without typing a password every time. Here the operation is simple: supply the password, the tool decrypts the streams, and it writes a new PDF with no encryption dictionary. The content is unchanged; only the wrapper is different. Our own tool does exactly this and nothing more. It does not guess, does not attempt recovery, and refuses the file if the password is wrong — which is the correct behaviour, and also why the error message matters: "invalid password" and "this is not a PDF" are completely different problems, and a tool that blurs them wastes your afternoon.

Why cracking tools are the wrong answer

Search results for unlocking PDFs are full of services promising to open any file. Against an owner password they are telling the truth and doing something trivial. Against a user password on a well-chosen passphrase they are selling brute force, which for AES-256 is not a matter of a longer wait — it is not going to finish. Where such services do succeed is against short, structured passwords: a six-digit date, a four-digit PIN, a customer number. That is worth knowing in both directions. It should make you sceptical of unlocking services, and it should make you think twice before protecting a genuinely sensitive document with your date of birth, which is exactly the password an attacker tries first.

Where the file goes matters

Anything you do with an encrypted PDF involves handing over both the document and its password. When that happens on a remote server you have, at that instant, given a third party a plaintext copy of a document you considered sensitive enough to encrypt, plus the key. Whether that is acceptable depends on the document — for a locked utility bill, probably; for a medical report or a contract, probably not. Running the operation inside your own browser avoids the question entirely, because the file and the password never leave the tab. This is one of the few places where the processing location is not marketing but a substantive difference in exposure.

A short checklist

Before you encrypt: decide who needs to open this in two years, and whether they will still have the password. Use a passphrase rather than a personal number, and send it separately. Before you decrypt: confirm you have a legitimate right to the document — the operation is trivial to perform and that is precisely why the responsibility sits with you rather than with the tool. And after either operation, open the result and check a middle page, because a file that opens on page one has not proved that the rest of it survived.