If a tool can remove the password, is PDF encryption useless?

Only the permissions kind is removable, and that was never encryption. A user password is real AES over the content — no tool can remove it without the password, because the streams are ciphertext and there is nothing to read.

Is it legal to remove restrictions from a PDF?

For a document you own or have the right to use, generally yes — you are rewriting your own file. Removing protection to redistribute someone else's work is a different matter and turns on copyright rather than on what the tool can do.

What encryption level should I choose?

AES-256 unless you have to support software older than about 2017. The older RC4 modes exist only for compatibility and none of them should be relied on now.

Why can I still open a PDF that says printing is not allowed?

Because opening and printing are governed by different mechanisms. Opening needs the user password, which in that file is empty. Printing is controlled by a flag your reader has chosen to honour.

how does pdf encryption work

How PDF Password Protection Works

A PDF can carry two passwords, and only one of them encrypts anything. The other is a request that readers are trusted to honour — which is exactly why it can be stripped.

One key, two doors

When a PDF is encrypted, a random file encryption key is generated. That key is what actually protects the content, and it is never stored in the file.

What is stored is two encrypted copies of it, in the `/O` and `/U` entries of the encryption dictionary. The user password unlocks one; the owner password unlocks the other. Supply either and you arrive at the same file key — which is the crucial detail almost nobody knows, and the source of most confusion about what protection means here.

The permission bits — may print, may copy, may modify — are stored in the encryption dictionary as a plain integer. They are not enforced by cryptography. They are a statement of intent that a conforming reader agrees to respect.

Why removing an owner password is not cracking anything

Almost every PDF that restricts printing or copying has no user password at all. The file opens instantly in any reader because the user password is the empty string — and the empty string derives the file key.

So a tool that removes restrictions is not attacking the encryption. It decrypts the file exactly as your reader does, with the empty password, and writes out a copy without the permission flags set. The content was never hidden from anyone who opened it; the file simply asked readers not to allow certain actions.

This is a genuine design decision rather than a flaw, and the specification is candid about it. Permissions exist to express intent to cooperating software. Any program willing to ignore the flags — and any program that can display the page can, since it has already decrypted the content to render it — is unaffected by them.

User password: Real encryption. Without it the streams are ciphertext and nothing can render the file. Not removable without the password.
Owner password: Sets permission flags. The content is already decryptable with the empty user password, so removal is a rewrite, not an attack.
Both set: You need the user password to open it at all. Once open, restrictions are as removable as ever.
Neither: No encryption dictionary. Nothing to remove.

What is actually encrypted, and how

Not the whole file. The object structure, the page tree and the cross-reference table stay readable — a reader has to navigate the document before it can decrypt anything. What is encrypted is the content: stream data and strings.

Each object gets its own key, derived by hashing the file key together with that object's number and generation number. This is why two identical images in the same file encrypt to different bytes, and it is also why an encrypted object cannot be renumbered — the number is part of its key. Merge and split tools must decrypt before they can copy anything.

The algorithms, and which ones still mean anything

The security handler has been revised repeatedly, and the version in a file determines how much the password is worth.

RC4 40-bit (PDF 1.1): Effectively no protection. The key space is small enough to search exhaustively on ordinary hardware.
RC4 128-bit (PDF 1.4): Better key length, but RC4 is no longer considered sound and the key derivation is a small number of MD5 rounds — cheap to attack by guessing passwords.
AES-128 (PDF 1.6): A sound cipher. The weakness remaining is the fast key derivation.
AES-256, revision 6 (PDF 2.0): The current standard. Deliberately expensive key derivation, so guessing passwords is slow. A strong password here is genuinely strong.

What this means for how you use it

If the document must not be read by the wrong person, set a user password, use a modern encryption level, and send the password by a different channel from the document. A password emailed in the same thread as the file protects against nothing.

If you only want to discourage casual copying or printing, an owner password does that and no more. It is a courtesy notice with real force among cooperating software and none at all otherwise. Treating it as security is the mistake worth avoiding — anyone motivated enough to want the text can select it in a reader that ignores the flags, or run OCR on a screenshot.

And when a document genuinely must not be edited rather than must not be read, flattening is usually the better instrument. It merges annotations and form fields into the page so there is nothing left to interact with, and it does not depend on anyone honouring a flag.