Password protect PDF files
Put a password on a PDF, and see which lock you actually set. Runs in your browser — no upload, no account.
Runs in your browser 0 bytes uploadedDrop the PDF you want to protect
Nothing is uploaded, and neither is your password. The file is encrypted on this machine.
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 does not survive, measured on real files
Encrypting a document rewrites its container, and some things do not make the journey. Rather than list the usual disclaimers, the tool counts them in your actual file before you run anything — a document with no bookmarks is not warned about bookmarks.
Document metadata is removed outright: title, author, subject, keywords and the producer strings. That is a deliberate choice rather than an accident, and the reason is unflattering to the tooling available in a browser. The encryption routine we rely on encrypts the streams that hold your pages, which is the part that matters, but it writes short text values in the clear inside a file that announces they are encrypted. Readers then attempt to decrypt plain text and get nonsense. Left alone, your document title would sit inside the protected file both broken and readable to anyone with a text editor — which for a file named after something sensitive is the exact opposite of what you came here for. Deleting those entries is the honest repair. If you want that cleanup on a file you are not encrypting, stripping PDF metadata is its own page.
Fillable forms are the other casualty, and only halfway. Whatever was typed into a field stays visible and printable on the page, because that text is drawn into the page itself. The field names do not survive, so any system that expects to read answers back by field name comes away empty-handed. Fill a form in and send it before protecting it, not after. Digital signatures break as well, 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.
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.
Questions
Where does the file go while it is being encrypted?
Nowhere. It travels from your disk into this tab and back out again as a download; the cipher runs on your own processor and the finished bytes live in memory belonging to this page. The reason that matters more here than on most pages is a small absurdity in how this task is usually performed online: a file you have just classified as worth encrypting gets transmitted, still unencrypted, so that a stranger's machine can encrypt it and send it back. Verification takes under a minute. Open your browser's network panel, run something through, and watch what leaves. Nothing does, because no code capable of sending it was ever downloaded.
Which encryption does this use, and what is the revision?
AES-128 by default, written as /V 4 and /R 4 in the file. AES-256 is available and writes /V 5 with revision 5 — and revision 5 is the part almost nobody names. It is Adobe's 2009 extension, superseded by revision 6 in ISO 32000-2, and its weakness is the password check rather than the cipher: revision 5 validates a guess with a single SHA-256, while revision 4 runs about fifty hashing rounds and revision 6 deliberately runs far more. So the AES-256 option gives you a stronger cipher and a cheaper password check at the same time. For a password a person chose, the password check is the thing under attack, which is why the default is AES-128. Both numbers are printed on the receipt, read back out of the finished file.
What is the difference between the two passwords I am offered?
They are two unrelated mechanisms wearing one word. An open password encrypts the page content: nothing renders without it, which is real cryptography, and it also means a forgotten password is a destroyed file. A permissions password hides nothing whatsoever. The document opens for anybody, and what the password installs is a set of flags requesting that reader software decline to print, select or edit. Conforming readers comply because the specification asks them to, not because anything in the file stops them. This page keeps the two in separate boxes and then names the one you ended up with, since the whole failure mode here is believing you got the first when you got the second.
Can your own tools remove the protection I just applied?
Partly, and we would rather admit it than let you find out later. Set only a permissions password and our own remover strips it in a single click, having asked you for nothing — as will most other software, because the specification allows exactly that. Go and try it on the file you just produced; the demonstration costs thirty seconds and is worth more than any assurance we could write. Set an open password and neither our tools nor anyone else's will get through without the string. That lopsidedness is the reason this page insists on naming your result instead of reporting a cheerful success.
Why can I not choose RC4, and why is 40-bit missing?
Because offering it would undo the purpose of the page. RC4 with a 40-bit key is still what you get from any export option phrased as compatible with Acrobat 3.0 and later, and its problem is not the password at all: the key space is small enough to search directly, so the password never has to be guessed. RC4 with a longer key avoids that specific hole but relies on a cipher no one selects deliberately any more. If some very old device genuinely requires one of them, an old Acrobat compatibility setting will still produce it — but you should know what you are asking for, and we are not going to hand it over quietly.
What happens to a fillable form or a signature?
Halfway, and the halves are worth separating. Anything already typed into a field stays visible and printable, because that text is painted onto the page itself. The fields keep their count too, since we re-save the document rather than rebuilding it from its pages. What they lose is their names, so any system expecting to read answers by field name comes back empty-handed. Complete and submit a form before protecting it. Signatures are simpler and worse: encryption alters the byte sequence a signature vouches for, so an existing one stops validating, everywhere and by anyone. Sign afterwards.
What if the PDF already has a password on it?
The tool says so before you do anything, names which of the two locks is on it and which encryption it uses, and then declines to re-encrypt it. That is a real limitation and not caution for its own sake. Re-encrypting an already-encrypted file was measured to leave a stale encryption object behind when the source uses object streams — harmless in every reader we tested, but untidy in a file whose whole job is to be trustworthy. The two-step route is complete and stays in your browser: take the old lock off with our password remover, then come back here and apply the new one.
Is there a size limit, and how long does a big file take?
No limit is imposed. Encryption was measured at roughly forty milliseconds per megabyte and it scales linearly, so the tool can tell you what to expect from your actual file before you start rather than after. A fifty-megabyte document is about two seconds of work. The tab stays responsive throughout, because the writer is told to hand control back after every object rather than every fiftieth — that costs about fourteen percent more total time and cuts the longest single freeze from roughly nine hundred milliseconds to sixty. Memory, not time, is the wall you would actually hit: the source, the encrypted result and the download are all held at once.