Password protect a PDF
Encrypt a PDF so it cannot be opened without the password, and see which of the two passwords in the specification you are setting.
How it works
A PDF password is not a wrapper around the file. The standard security handler described in ISO 32000-1 clause 7.6 encrypts each string and each stream on its own and leaves everything else legible. Object numbers, dictionary keys, the cross-reference table, the page count, the name of every embedded font: that is structure rather than content, and a reader has to walk it before it can ask anybody for anything. The encryption dictionary is readable by design, because it holds the values a reader needs in order to test what was typed.
In the 2,364-byte document this tool produced from a three-page source while the page was being written, `/Filter /Standard`, `/V 4`, `/Length 128` and `/R 4` sit in plain view from byte 1,340, and the permission integer sits beside them. What is absent is the page text and the document title. Both went into an object stream, and an object stream is a stream.
The two passwords
The specification defines two of them. The user password opens the document under whatever restrictions the file declares. The owner password opens it under none and is the one a reader treats as authority. A reader handed a single string tests it as the owner password first, by the procedure in Algorithm 7, and only falls back to the user test in Algorithm 6.
That ordering has a consequence most tools never mention. If both passwords are the same string, everybody who can open the document holds owner authority, so the restrictions bind nobody. This page therefore fills both from one field while nothing is being restricted. The moment printing or copying is denied, the owner password becomes 128 bits from `crypto.getRandomValues` that nothing here stores or displays, since a restriction liftable with the password the recipient was already given is decoration. The consequence is worth stating plainly: nobody can lift it later, and that includes you.
What the permission bits are
`/P` is a single 32-bit integer with its bits counted from 1. Bit 3 is printing, 4 is modifying, 5 is copying, 6 is annotating, 9 is filling in form fields, 10 is extracting text for accessibility, 11 is assembling pages, and 12 is printing at full resolution. Every reserved bit has to be set, so an integer that denies all eight reads as -3904 in two's complement rather than as some small number.
Denying printing and copying and leaving the rest alone gives -2072, and that is the value measured coming out of this tool. pdf.js read the same file back and reported permissions 8, 32, 256, 512 and 1024: modifying, annotating, form filling, accessibility extraction and assembly, with printing and copying absent from the list. The integer travels intact. Whether it is obeyed is a separate matter.
By default it is not obeyed by pdf.js, the engine inside Firefox's built-in viewer. In pdfjs-dist 6.2.108 the viewer option `enablePermissions` carries the value false, and the text layer's copy handler withholds the clipboard only when that option has been turned on. At the API level the denial is never consulted: `getTextContent()` returned “Page 2 of 3” out of the document described above, whose `/P` forbids copying. Adobe Acrobat does honour the bits, so setting them still buys something. They are a request addressed to well-behaved software.
Forty bits, and why the number is still reachable
Revision 2, the only revision PDF 1.3 could describe, uses a 40-bit RC4 key. The ceiling was regulatory rather than technical: United States export rules capped exportable cryptography at 40 bits until they were relaxed in 2000. PDF 1.4 added revision 3 with a 128-bit RC4 key, and PDF 1.6 added revision 4 with AES-128, which this tool writes. A 40-bit keyspace holds 1,099,511,627,776 keys, and an attacker never has to guess the password, because the file key is the shorter target.
The number matters here because of how the library picks a revision. `PDFSecurity` reads it off the header version string and from nowhere else, so a document arriving as %PDF-1.3 would have been encrypted at 40 bits with no option involved and no warning emitted. The header is set to 1.7 before encrypting, and the note under the download says when it had to be raised. Key strength is a property of this tool rather than of whichever file was dropped on it.
A 256-bit setting exists in the same library and is deliberately not offered. It writes revision 5, the design Adobe published for Acrobat 9 and that ISO 32000-2 replaced with revision 6. Revision 5 validates a password with one SHA-256 over the password and a salt, where revision 4 runs 51 MD5 rounds and 20 RC4 rounds to reach the same decision. Against the attack that actually happens, guessing the password, a longer key arrives with a cheaper guess.
What a password does not do
Encryption covers the file and not the situation. There is no expiry, no revocation and no record of who opened it. A recipient holding the password holds the document permanently and can save a copy with the encryption gone, using anything that can open it. None of the 128 bits help against a password somebody can guess, and the guess is shorter than it looks: Algorithm 2 pads or truncates to exactly 32 bytes, so the thirty-third character onwards is never consulted by any conforming reader.
Questions
Can the password be recovered if I forget it?
No, by anyone. Nothing here stores it: the password exists as characters in a form field in this tab, is turned into a key, and is gone when the page closes. The encrypted download is then the only copy of a document nobody can read, so put the password somewhere before you close the tab rather than after. If you have denied printing or copying, the owner password is random and was never shown to you either, so those restrictions cannot be removed by anybody at all.
Does denying printing actually stop someone printing?
It stops Adobe Acrobat, which honours the permission bits. It does not stop software that declines to check them, and that includes pdf.js: measured against pdfjs-dist 6.2.108, calling `getTextContent()` on a document whose `/P` denies copying returned the page text anyway, and the bundled viewer leaves its `enablePermissions` option false. Anyone who can open the file can also re-save it without restrictions. The bits are worth setting as an instruction and are worthless as a lock, so the open password is the part that enforces anything.
Which readers can open the result?
AES-128 at revision 4 arrived with PDF 1.6 in 2004 and is read by everything current. Verified in this session with pdf.js 6.2.108, an implementation sharing no code with the one that wrote the file: it opened the document with the correct password, reported all three pages, extracted the page text, and refused both an empty password and a wrong one. Acrobat, Preview and the Chrome viewer were not available to test here, so that claim rests on the format's age rather than on a measurement.
Why is there no box to confirm the password?
Because the field is an ordinary text input and shows what you typed, so a second box would only re-test a string you can already read. The typo a confirmation catches is the one you cannot see, and that is whitespace, so the note under the download reports the character count and says when the password begins or ends with it. Passwords longer than 32 characters are reported too, since a conforming reader stops reading at the thirty-second byte.