creatorvalet
Files Convert, compress and reshape files — without uploading them anywhere. Metadata See what your files quietly carry, then strip exactly what you choose. Text & data Formatters, converters, and the character-encoding fixes nobody else gets right. Publishing Check how your pages read to crawlers, to people, and to language models. Codes Barcodes, QR and identifiers that keep working after you publish them. Characters Find the character you can draw but cannot name — and the font you cannot place.

How to password protect a PDF

A PDF password is either real encryption or a polite note to the reader, and the dialog will not say which one you set. One test settles it in seconds.

Updated 2026-08-09

The clicking is the easy part, and it is written up in a hundred places: find Export or Protect, tick the box marked Encrypt, type something twice, save. Four clicks in Acrobat, four in Preview, four in a browser tab. Follow any of those guides and a padlock appears on the file.

What none of them tell you is what the padlock is made of. The format supports two completely different things that dialogs both label password, and only one of them is encryption. The other is a note attached to the document asking reader software to behave. Both produce the same reassuring padlock icon. Only one of them survives a determined recipient, and the guides that walk you through the four clicks do not say which one you just picked.

There is also a fact worth having before you start rather than afterward. Protection that works, works against you too. A correctly encrypted PDF whose password you have lost is not recoverable by us, by Adobe, or by anyone selling a service that says otherwise. That is the point of it. Decide where the password will live before you create the thing it opens.

Two locks share one word

An open password — the specification calls it the user password — encrypts the page content. Nothing can be rendered without the key, so a reader has no choice but to demand the string before it draws anything. This is the lock most people picture when they say they want to protect a file.

A permissions password, known in the specification as the owner password, does not hide the document at all. It opens for anybody. What it carries is a set of flags saying that printing is disallowed, or that text may not be selected, or that the pages must not be rearranged. Conforming readers honor those flags because the specification asks them to. Nothing in the file compels them. Software that quietly ignores the flags has broken no rule and no cryptography.

That second lock is a common and largely invisible cause of a different frustration: a document that opens perfectly well and then refuses to give up a single sentence, and it is a frequent answer to why a PDF will not let you copy its text. If your goal is to stop a colleague from lifting your paragraphs into a slide deck, this is the flag that does it, and it does it about as firmly as a please do not touch card.

Some applications label the pair honestly. LibreOffice, exporting to PDF, shows a Security tab with two separate buttons — Set Open Password and Set Permission Password — and seeing them side by side is the clearest one-second explanation of the distinction available anywhere. Plenty of other dialogs offer a single field called Password, and you are left to infer the rest.

The test that tells you which one you set

Whatever route you used, verifying the outcome takes about fifteen seconds and does not require any software you do not already have. Close the document completely. Open the saved copy again, from the file rather than from the still-open window.

If a box demands the password before a single page appears, the content is encrypted and you set the open password. If the document appears immediately and the restriction shows up later — Print grayed out, text refusing to highlight — you set the permissions password, and anyone you send it to can read every word. If it opens normally and nothing is restricted, nothing was applied, which happens more often than you would expect when a dialog offers a Permissions section that quietly stayed switched off.

There is a faster route that also names the algorithm. Drop the finished file on the PDF password remover and the first thing it prints is which of the two locks the file carries and what encryption is on it, read straight out of the file before anything else happens. It will not act until you tell it to, so you can read the verdict and close the tab. The file was never sent anywhere to produce it; the reading happens in the same tab you are looking at.

Strength is a number, and old software still writes the weak ones

PDF encryption comes in generations, recorded in the file as /V and /R. Version 1 is RC4 with a 40-bit key — trivially breakable today with rented hardware, and still exactly what you get from any export setting phrased as compatible with Acrobat 3.0 and later. Version 2 is RC4 with a longer key, usually 128 bits, and RC4 itself is no longer a cipher anyone chooses on purpose. Version 4 is normally AES-128. Version 5, paired with revision 6, is AES-256, and that is the one to want.

None of this is visible from the outside of the file, and no reader shows it to you while you work. It is legible, though, and cheaply: the encryption dictionary is the one structure in a PDF that is never permitted to be compressed inside an object stream. It could hardly be otherwise: the instructions for decompressing the rest of the document cannot themselves be locked away behind the decompression. So it sits in the clear, inside a file nobody can open. That is precisely why our page can tell you AES-256 or RC4, 40-bit about a document it has no password for.

The practical advice is short. If your software offers a compatibility setting, choose the newest one the recipient can open. If it does not offer one, check the result rather than assuming, because a default written in 2004 does not announce its age.

What the password does not cover

Encryption protects a document in transit and at rest. It does not follow the document into the hands of the person you sent it to. Somebody who can open the file can print it to a new PDF, export it, screenshot it, or simply save an unprotected copy — and for the permissions variety, they need not even do that much, since any application that declines to honor the flags will hand over the text on request.

The same misreading turns up in spreadsheets, where sheet protection looks like security and is documented by Microsoft as not being any, which is why unprotecting an Excel workbook needs no password while an encrypted workbook genuinely cannot be opened without one. The lesson carries between formats even though the remedies never do: ask whether the lock is enforced by mathematics or by etiquette.

So a password is right for a payslip sent over email and wrong as a substitute for not sending the document at all. It narrows who can read the file to people who have the string. It has nothing to say about what they do next.

About the upload, and about which revision you get

Most of the top results for this question ask you to upload the file first. It is worth being precise about why that is worth a thought rather than an accusation: the document you have just decided is sensitive enough to encrypt travels to somebody else’s server unencrypted in order to come back encrypted. The companies involved are established and their policies are public. The gap is not honesty, it is verifiability — what happens on a machine you cannot see is a commitment rather than a mechanism. If you want to check any page, including this one, verifying local processing is a one-minute procedure with the network panel open.

And the honest note about us, which now comes with a caveat rather than an apology. Our own page for password protecting a PDF does the job in the tab you are reading this in, tells you which of the two locks you just set, and prints the /V and /R of the finished file instead of leaving you to work it out. The caveat is the one this article has been building towards, and it applies to us too: the strongest option a browser can write is AES-256 at revision 5, not revision 6. Revision 5 checks a submitted password with a single hash, where revision 4 runs about fifty rounds and revision 6 runs far more, so our default is deliberately AES-128 and the AES-256 option carries its revision printed next to it. If your requirement is specifically revision 6, no browser will give it to you and you should reach for Acrobat.

The offline routes are still there and still good: Preview on macOS, LibreOffice on any platform, Acrobat if you have it. None of them tells you what it just wrote, which is the gap worth knowing about whichever one you pick — and it is why the fifteen-second test above is worth running regardless. If you have ended up here wanting the opposite direction, the companion piece on taking a PDF password off again starts from the same two locks and works out which of them is standing in your way.