Password protect PDF files

Password protect PDF files, and see what was actually written

Most pages that offer to lock a PDF report success and stop there. This one prints the encryption dictionary it just produced, read back out of the finished bytes rather than echoed from the settings you chose. You get three numbers: the algorithm name, the version marker the format calls /V, and the revision marker it calls /R. The last of those is the one nobody quotes, and it is the one that decides how much work a determined guesser has to do.

Choose AES-128 and the file carries /V 4 with revision 4. Choose AES-256 and it carries /V 5 with revision 5. That second pairing deserves a sentence rather than a marketing badge. Revision 5 is Adobe's extension from 2009; the international standard that followed introduced revision 6 and left 5 behind. The difference between them is not the cipher — both scramble the pages with AES using a 256-bit key — but the check that decides whether a submitted password is the right one. Revision 5 answers that question with a single SHA-256 computation. Revision 4 grinds through roughly fifty rounds of hashing first. Revision 6 deliberately grinds through far more than either.

So the option labeled with the bigger number gives you a stronger cipher and a cheaper password test at the same time, and somebody working through a list of candidate passwords is testing, not attacking the cipher. Since AES-128 has never been broken, the default here is the one that makes each guess expensive. AES-256 stays available, because plenty of procurement checklists contain the string "AES-256" and refusing to produce it would only send you somewhere that prints those characters without ever mentioning a revision. The library available to a browser cannot write revision 6 at all, and saying so is better than quietly implying otherwise.

Two locks, and which one you end up with

The format offers two mechanisms that software everywhere labels with the same word. This page keeps them apart on purpose, as two separate fields, because collapsing them into one box is how people end up believing a document is sealed when it is not. Fill in the open password and the page content is genuinely encrypted. Fill in only the permissions password and the document opens for anybody who double-clicks it; what you have set is a request that reader software decline to print or copy, honored out of politeness rather than mathematics.

The receipt names which of the two you got, and it does not soften the second case. If you set only the permissions password, the receipt says so and links to our own tool for taking a PDF password off, which strips exactly that lock in one click without being handed any password at all. You are invited to go and do it to the file you just made. A claim you can falsify in thirty seconds is worth more than a reassuring sentence, and we would rather you learn this from us than from whoever you were trying to keep out. For the wider background — how the same confusion shows up in the dialogs on your own machine, and how to check afterward which one a program gave you — the guide covers ground this page does not.

Permissions default to allowed, because the library defaults the other way

There is a trap in the underlying code that is worth describing, since a tool built carelessly on top of it would inherit the problem invisibly. Ask that library to encrypt a document without spelling out a permissions list, and it writes a file that forbids everything: printing, copying, editing, commenting, filling in forms, rearranging pages, and extracting text for assistive software. Somebody who wanted nothing more than an open password would receive a document that also shuts out screen readers, and no dialog anywhere would mention it.

This page therefore always sends a complete permissions list, and that list starts from everything being allowed. The only things switched off are the boxes you tick, and those boxes only appear once you have set a permissions password, since restrictions without one are not a meaningful thing to ask for. One bit is deliberately absent from the interface: the flag that blocks text extraction for accessibility tools is always left on. Blocking it stops assistive software and nobody else, because anyone intent on lifting your text was never going to be stopped by a flag in the first place.

What survives the rewrite, measured on real files

Encrypting a document rewrites its container. Rather than repeat a generic preservation promise, the tool counts metadata, form fields and bookmarks in your actual file before you run anything — a document with no bookmarks is not given a bookmark claim.

The underlying writer encrypts page streams but omits short PDF strings. Left alone, that would put a title or form-field name in clear text inside a file that declares it encrypted, and a standards-compliant reader would decode it as nonsense. This tool completes that missing step before saving: every direct string is encrypted with the same per-object key as its stream. Titles, authors, subjects, form-field names and bookmark titles therefore remain readable with the password and absent from the raw bytes without it. If you want to remove those values instead, stripping PDF metadata remains its own job.

Fillable forms keep their field names, values and interactive controls. Digital signatures are different and still break, unavoidably and everywhere: encryption changes the byte sequence the signature was issued over. Sign after protecting.

Already locked? We send you round the other way first

Hand in a file that already carries a password and this page declines the job. It says which of the two locks is on it and which encryption it uses, both read straight out of the bytes without opening anything, and then it points you at the remover. The reason is measured rather than fussy: putting fresh encryption over existing encryption leaves an orphaned encryption object in the output when the original used compressed object streams. Every reader we tested opened those files correctly, so this is tidiness rather than danger — but a file whose entire purpose is to be trustworthy is a poor place to leave something that merely happens to work. Take the old lock off, come back, apply the new one. Both halves run in this tab.

One ordering note, because it catches people out. Encryption is the last step in a document's life, not the first: anything that has to edit the file has to decrypt it, and most tools that do so hand back an unprotected copy. So if the document still needs a signature on it, sign the PDF first and protect the signed copy here afterwards. Doing it the other way round means unlocking, signing and re-protecting, and the last of those three steps is the one people forget.

Size, speed, and the reason there is no progress bar

Nothing is refused for being large. Encryption was timed across files of five, twenty and fifty megabytes and came out at roughly forty milliseconds per megabyte on all three, so the estimate you see before you start is arithmetic on your own file rather than a guess. A fifty-megabyte document is about two seconds of work.

What you will not see is a percentage, and that is a decision rather than an oversight. The writing step reports nothing about its own progress, so any number moving across the screen would be a stopwatch pretending to be a measurement. Instead the panel names the step that is genuinely running. The tab does stay usable while it works: the writer is instructed to hand control back after every single object rather than after every fiftieth, which costs about fourteen percent in total time and cuts the longest uninterrupted freeze from roughly nine hundred milliseconds down to sixty. Memory, not time, is the wall you would actually hit, since the original, the encrypted result and the pending download are all held at once.

None of it leaves the machine. The document is read from your disk into this tab, the encryption runs on your processor, and the password travels from a form field into a function and no further — never into the address bar, never into storage, never into an error message. That last one matters more than it sounds: messages that repeat what you typed have a habit of turning up in places nobody planned. If you would rather check than trust, open the network panel and protect something. The request carrying your file does not exist.