Secure PDF Document

Two passwords, and only one of them is a lock

A protected PDF can carry two different passwords, and almost every problem people have with them comes from treating the pair as one thing. The open password encrypts the document. Without it the contents are not hidden, they are unreadable — there is no text to extract, no image to lift, nothing to look at but ciphertext. The restrictions password, which the specification calls the owner password, does not encrypt anything on its own. It is the key to the rules: whoever holds it can change or remove every permission attached to the file.

That is why this tool asks for the restrictions password and treats the open password as optional. Set only the restrictions password and you get a file anyone can read but that asks readers not to print, copy or edit it. Set both and you get a file that cannot be opened at all without the first password, and that carries your rules for anyone who gets past that point. Share the open password with the people who should read the document; keep the other one to yourself, because handing both to the same person makes the restrictions meaningless.

Setting them to the same string is the common mistake, and the tool refuses to do it. If the open password and the restrictions password are identical, every recipient you give the file to can also lift every restriction you set, which leaves you with the inconvenience of a password and none of the control you wanted.

What the five encryption strengths actually write into the file

PDF encryption is not one thing. The standard security handler has been revised repeatedly since 1996, and a file records which revision it uses in its encryption dictionary. The choice matters in two directions at once: newer revisions are harder to attack, older ones open in more software. These are the five this tool can produce, and what each one puts in the file.

Unless you know that a specific old program has to open the file, take the default. AES-256 revision 6 is the version defined in ISO 32000-2, the current PDF standard, and there is very little left in circulation that cannot read it. The two RC4 options exist because compatibility problems are real, not because they are reasonable choices for anything sensitive: RC4 has known weaknesses, and forty-bit RC4 is breakable by anybody who decides to bother.

The strength you pick is written into the file and can be read back out of it. After protecting a document, the results panel reports the cipher, the revision and the key length it found by reading the finished file's encryption dictionary — not by repeating the setting you chose. If those two ever disagreed, you would be told the truth rather than the intention.

Why revision 6 matters more than the number 256

AES-128 and AES-256 are both unbroken. Nobody is going to read your document by attacking the cipher. What they will attack is the password, by guessing, and the thing that decides how expensive guessing is has nothing to do with the key size — it is how much work the format makes an attacker do to test each candidate.

Under revision 5, testing a password is a single SHA-256 hash. Under revision 6 it is Algorithm 2.B: at least sixty-four rounds, each one an AES-128-CBC pass over several kilobytes followed by a SHA-256, SHA-384 or SHA-512 depending on the bytes that came out. The difference, measured in an ordinary browser on ordinary hardware, is this.

Adobe deprecated revision 5 for exactly this reason. Both write AES-256 into the file and both look identical in most software's properties dialog, so the distinction is easy to miss and worth understanding: revision 5 gives you a strong cipher guarding a cheap password check. This tool defaults to revision 6, and offers revision 5 only for readers old enough to need it.

None of which rescues a weak password. Five hundred times the work is decisive against a password that would have taken a week to guess and irrelevant against one in the first thousand attempts. The hashing buys time; the password decides how much time there was to buy.

Permissions are a request, and some of them cannot even be recorded

The eight permission flags — printing, copying, editing, commenting, form filling, page assembly, full-quality printing and screen-reader access — are stored in the file as a single number, and they are advisory. A reader that chooses to honour them will grey out the menu items you turned off. A reader that does not will print, copy and edit your document freely the moment it is open, and stripping the flags out of a file is not difficult. Use permissions to prevent honest accidents and to state your intent, never to stop somebody who has decided otherwise. The open password is the only part of this that is enforcement rather than etiquette.

There is a second limit that almost nothing tells you about. The permission flags live in a bitmask, and the older revisions of the security handler simply do not have bits for all eight. Revision 2 — what you get if you choose RC4-40 — has room for four of them. The other four are not denied and then ignored; they are recorded as allowed, whatever you asked for.

Screen-reader access is a special case, and it stays switched on at every strength here. ISO 32000-2 deprecated the ability to restrict it, and in practice blocking it does very little to a determined copier while shutting out people who rely on assistive technology to read a document at all.

What travels inside a PDF that you never typed

Every PDF carries a small block of information about itself: title, author, subject, keywords, the software that produced it, when it was created and when it was last changed. Most of it is filled in automatically, and it is visible to anyone with the file — no password required, because in most files that block is written before any encryption applies. A document exported from a work laptop routinely names the person who wrote it and the software licence it was made under, which is often more than the sender intended to share.

The tool lets you rewrite any of those fields, or erase the lot. Two details are worth knowing because they were measured rather than assumed. First, the producing-software field is rewritten by the encryption step whatever you do, so it will name the library rather than whatever made your original. Second, the modification date is set to the moment you protect the file, and the original creation date survives untouched — so a file you protect today still says when it was first written. Ticking Erase the existing details blanks all of it, both date stamps included. On anything leaving your organisation, that is the setting to use.

What does not change is the document itself. Pages are never re-rendered, re-compressed or re-flowed. The page content is passed through untouched and only the security dictionary and, if you ask for it, the details block are rewritten, so fonts, images, layout and page count come out exactly as they went in. The file usually grows by a few per cent, because encrypted data does not pack as tightly as plain data and the security dictionary itself takes room.

Reading a locked PDF's rules without its password

The situation nobody builds for is the one where somebody sends you a protected PDF and you need to know what you are allowed to do with it before you plan around it. Can it be printed for a meeting? Can a quote be copied out of it? Will the pages go into a combined pack?

The second tab answers that. It reads the encryption dictionary and the permission bitmask straight out of the bytes and reports what the file permits, along with the cipher, the revision and the key length. It needs no password, it never asks for one, and it changes nothing — the file is only read. It is also the honest way to check your own work: protect a document, feed the result back in, and confirm it says what you meant it to say.

If the answer comes back as RC4-40 or RC4-128 on a document that matters, that is worth acting on. A file protected years ago with the settings of the day is not protected to today's standard, and if the document is yours you can simply protect it again at AES-256.

Choosing a password worth the encryption behind it

The encryption is the easy part. Every serious failure of a protected PDF is a failure of the password, and there are only a few things that actually matter.

Length beats decoration. A long, ordinary passphrase is far harder to guess than a short one with a symbol wedged in the middle, and much easier to type on a phone or read down a telephone line. Four unrelated words is a better password than P@ssw0rd! by an enormous margin, and the tool's Suggest button builds exactly that: four words from a fixed list plus two digits, drawn from your browser's cryptographic random source.

The strength meter can be wrong, so it is not the only check. Character-counting arithmetic scores password123 at a comfortable-looking number while it sits near the top of every breach list ever published. The tool checks candidates against the passwords attackers try first and names the problem instead of scoring it.

Type it twice, and keep a copy of the original. There is no recovery. A typo in an open password produces a file that nobody can open, including you, and no amount of ownership or evidence changes that. Both password boxes are confirmed for this reason, and the sensible habit is to keep the unprotected original somewhere safe before you protect anything that matters.

Send the password by a different route than the file. A password in the same email as the attachment protects against nothing except a wrongly typed address. Send the document by email and the password by phone, message or in person.

Protecting a batch without repeating yourself

Settings apply to every file you drop in, so a folder of invoices or a set of board papers can be protected in one pass with the same passwords, the same strength and the same permissions. Each file gets its own row, its own result and its own Save link, and a batch can be taken away as a single ZIP rather than a queue of separate downloads.

Files that cannot be protected say why on their own row instead of failing quietly. The usual reason is that the file is already encrypted, which has to be undone in a reader that has the password before the document can be protected again with different settings — this tool will not guess or remove an existing password.

Every file that does succeed is opened again before you are offered it. The finished bytes are loaded back with the password that was just set and the page count is compared against the original; anything that fails that check is reported as a failure rather than handed over as a download that might be damaged.

What this tool will not do

It will not remove or recover a password. If a file is already encrypted and you do not have the password, nothing here will help, and that is a property of the format rather than a limitation of the page.

It will not make permissions enforceable. They are recorded faithfully and honoured by cooperative software, and that is all any PDF tool can offer.

It will not encrypt to a certificate or a recipient's public key. This is password-based protection with the standard security handler, which is what the overwhelming majority of protected PDFs use.

And it will not upload anything. The encryption library is JavaScript served from this site, the revision 6 key derivation uses your browser's built-in WebCrypto, and the file never leaves the tab. Once the page has loaded you can disconnect from the network entirely and it will still work — which is the only demonstration of a privacy claim that is worth anything.

Questions people ask about PDF passwords

Which password do I give the person receiving the file?

The open password, and only that one. It is the password that lets them read the document. The restrictions password is your key to the settings; anyone who has it can remove every restriction on the file, so it should not travel with the document.

Is AES-256 worth choosing over AES-128?

Yes, but not for the reason most people assume. Neither cipher is anywhere near being broken, so the key size is not what protects you. AES-256 is the default here because it comes with revision 6, which makes each password guess hundreds of times more expensive. If something in your workflow needs AES-128, a long passphrase on AES-128 is stronger in practice than a short password on AES-256.

Why is the restrictions password required when the open password is not?

Because the permission flags belong to the owner half of the security handler. Without an owner password there is nothing to attach them to, and the file would carry no restrictions at all. An open password is a separate decision: it is the difference between a document anyone can read under stated conditions and one nobody can read without a key.

Someone opened my protected PDF and printed it anyway. What went wrong?

Nothing went wrong technically. They used software that does not honour permission flags, which it is free to do. Restrictions are advisory and always have been. If printing must be impossible rather than discouraged, a PDF password is the wrong instrument — you need control over who can open the document at all, which is what the open password gives you.

Can I protect a file that is already protected?

Not directly. An encrypted PDF has to be opened with its existing password and saved without protection before new settings can be applied. The tool reports this on the file's own row rather than failing without explanation.

Will the protected file open on a phone?

Yes. Every mobile PDF reader in current use handles AES-256, and the file behaves the same way it does on a desktop: the reader asks for the open password before showing anything. The only reason to move down to an older strength is a specific old application that has to open the file.

Does protecting a PDF reduce its quality?

No. Nothing is re-rendered or re-compressed. The pages are copied through unchanged and only the security information is added, so text stays selectable, images keep their original resolution and the page count is identical. The file grows slightly because encrypted data compresses less well.

How do I check that a file really is protected the way I intended?

Feed it back into Check what a PDF allows. It reads the file's own encryption dictionary and permission bits and reports them, so you are looking at what is in the document rather than at what any tool claims it did.