PDF passwords explained: what "protected" really means

You password-protect a payroll summary and email it to a colleague. Then, because they'll obviously need it, you email them the password — from the same account, to the same inbox, ninety seconds later. Almost everyone has done this. It's worth understanding what the password was protecting against in the first place, because a PDF can carry two completely different passwords, and one of them is barely protection at all.

Two passwords, two different jobs

This is the single most useful thing to know about PDF security, and most software hides it behind a checkbox.

The user password (often called the open password). Without it, the file will not open. The content is encrypted, and the password is what unlocks the key. This is real protection: no password, no document.
The owner password (often called the permissions or master password). The file opens for anyone, with no prompt. The password only governs what the reader is told to allow — printing, copying text, editing, annotating.

You can set either, or both. If you set only an owner password, the document opens freely and its "restrictions" ride along as flags.

The short version: a user password locks the door. An owner password puts up a sign asking people not to come in. Only one of them is encryption in any meaningful sense.

Why the owner password is weaker than it looks

Here's the part that surprises people. When a PDF carries only an owner password, it still has to open without anyone typing anything — so the file is encrypted with a key that any reader can derive on its own. The document is, for practical purposes, already unlocked. The permission flags are just values stored in the file saying "please don't allow printing".

A well-behaved reader honours that request. Adobe Acrobat greys out the print button, and that's genuinely useful for preventing accidents — a colleague won't casually print the confidential draft. But the restriction depends entirely on the reader choosing to cooperate. Software that doesn't cooperate simply doesn't, and it isn't doing anything clever to get there.

That's why tools can remove owner-password restrictions instantly, while a strong user password stops them dead. It isn't a flaw in any particular program — it's the design. Owner passwords express intent; user passwords enforce it.

What the encryption actually is

When a user password is set, the content is genuinely encrypted. The scheme has evolved considerably:

Legacy RC4 (40-bit, later 128-bit). Found in older documents. The 40-bit variant is thoroughly obsolete and should be assumed breakable. Treat any RC4-era file as protected by habit rather than mathematics.
AES-128. A serious step up, and still respectable for ordinary business documents.
AES-256. The modern option, and the sensible default. With a good password, this is strong encryption in the ordinary sense of the phrase.

Which matters less than you'd hope, because of the next point.

Your password is the weak part — not the algorithm

Nobody attacks AES-256. They guess. Encryption converts the problem of reading your document into the problem of guessing your password, and if the password is Invoice2026 then that problem is not hard. A guessing program doesn't try random strings; it tries words, names, years, and the substitutions people believe are clever.

So the practical advice is dull and correct: a long passphrase of unrelated words beats a short "complex" password with a $ in it. Length is what costs an attacker time. And because you'll need to tell someone the password anyway, memorable-and-long is a better target than cryptic-and-short.

The delivery problem

Encryption moves the secret rather than removing it. Now you must get the password to the recipient — and if it travels in the same email, you have achieved nothing beyond a small speed bump. Anyone who can read the message can read the attachment.

Send the password through a genuinely different channel: a phone call, a text message, a signal you agreed on beforehand. Not the reply. Not the same thread. This one habit does more for real security than any choice of cipher.

How to protect a PDF

Open the Protect tool. Go to Password Protect PDF. It runs in your browser.
Choose your PDF and set a user password. If your goal is that people without the password cannot read the file, it must be a user password. An owner password alone will not do that.
Pick a long passphrase. Several unrelated words. Length over symbols.
Send the password separately. Different channel. Not the same email.

Open the Password Protect tool

How to remove a password you already have

Once a document has served its purpose, the password often becomes an obstacle — an archived contract nobody can search, a statement you re-open monthly. If you have the password, you can remove it:

Open the Unlock tool. Go to Unlock PDF.
Load the file and enter the current password. This is a document you can already open — the tool removes protection, it does not defeat it.
Export the unlocked copy. Then consider whether it should be encrypted at rest some other way, such as on an encrypted drive.

Open the Unlock PDF tool

To be explicit about the boundary: this removes protection from a file you have the password for. It does not crack unknown passwords, and no honest tool claims to.

What a password can't do

A protected PDF is protected in transit and at rest. It is not protected from the person you sent it to.

It isn't DRM. Once someone can read the document, they can screenshot it, retype it, or photograph the screen. No document format has ever solved this.
"No copying" is a request. The permission flag asks readers not to allow selection. Text is still text in the file.
It doesn't hide metadata. Author names and timestamps travel inside the encrypted file and reappear the moment it's opened. Clean those separately — see what's hidden in your PDF.
It doesn't prove who sent it. Encryption is about confidentiality, not authenticity. For that you want a signature or a hash — see proving a document hasn't changed.

If your real requirement is "they can read it but not keep it", a password is the wrong instrument. A view-only export that flattens the document to non-selectable pages is closer to the intent — though even that cannot beat a camera, and it's more honest to say so.

Why do this locally?

Setting a password on a document usually means the document matters. Uploading it to a stranger's server to have that password applied means handing them the unprotected original first — which is precisely the file you were trying to protect. Doing it on your own device avoids the contradiction. In CyvoDocOps, supported operations of this kind run locally in your browser and the document is not uploaded to a server.

Frequently asked questions

What's the difference between the two passwords again?

The user (open) password is required to open the file at all. The owner (permissions) password lets the file open freely but marks restrictions like "don't print". Only the user password meaningfully keeps people out.

Can I recover a PDF password I've forgotten?

Not through us. A strong user password with modern encryption is not recoverable by design — that's the point of it. If it were, it wouldn't be protection.

Is AES-256 enough for confidential documents?

The algorithm is not the weak link; your password is. AES-256 with a short, guessable password is weak protection. AES-256 with a long passphrase is strong.

Why can some tools remove restrictions instantly?

Because a file with only an owner password isn't really locked — it opens without a password by design, and the restrictions are flags that cooperating readers choose to honour.

Does my file get uploaded?

No. For these tools the PDF is processed locally in your browser and is not sent to a server.