PDF permission passwords are one signed integer, and readers decide whether to honor it

A password that never asks

Opening a PDF without a password prompt does not mean the file is unencrypted. According to a post on dev.to, a document can open freely and still carry AES-256 encryption, and the reason is a single signed integer in the file's encryption dictionary — one that nothing in the format obliges any reader to respect. To trace that contradiction, the author scripted seven two-page sample files: one with no encryption, five protected only by a permission password (an empty user password paired with a set owner password), and one that demands a password to open.

One field, eight switches

The field in question is /P, a 32-bit value stored as a signed number inside the /Encrypt dictionary. Every bit that is set grants an action; every cleared bit denies one. Bits 3 through 12 map to printing, modifying, copying, annotating, form filling, accessibility extraction, assembling, and high-quality printing. The samples illustrate the range: a value of -3392 (0xFFFFF2C0) keeps only accessibility extraction and denies the other seven; -20 clears just the copy bit; -2056 blocks printing and high-quality printing; and zero denies everything, accessibility included. The neighbouring V, R, Length and crypt-filter entries choose the cipher, and the author found that the cipher made no difference to behaviour.

A short pypdf snippet accompanying the post reads the dictionary directly from the file trailer, without decrypting anything, and names the actions each P value denies. It is reporting only: it never writes a file and never asks for the owner password.

Empty password, real encryption

The streams in a permission-only file are genuinely encrypted. The encryption key derives from the user password, which is empty, so every viewer derives it silently and opens the document without a prompt. The author's reading is that this encryption mostly serves as the container the Standard security handler needs in order to carry the P value, rather than a lock on the content.

Libraries even disagree about what to call this state. PyMuPDF reports such a file as not encrypted once it has opened it, while pypdf reports it as encrypted because the dictionary exists. The author's warning for developers: if your code checks a single boolean, find out which of the two meanings it carries.

Every viewer makes its own call

Once the content is readable, honoring P is a decision each reader makes. The author ran the same files through Chromium 149 (an open-source build, not Chrome), Firefox 151, and two libraries. Chromium's viewer blocked printing and copying but still allowed drawing on the page. Firefox on default settings let all three through; with pdfjs.enablePermissions switched on it blocked printing and editing while copying kept working. The two libraries simply handed the flags to the caller and rendered as usual. Files sharing a P value behaved identically in both browsers regardless of whether the cipher was AES-256, 128-bit RC4 or 40-bit RC4.

The tool that refuses

A compressor has to write a new file, which puts it in the enforcer's seat. The author fed ImgIng's PDF compression, via its Chinese interface, the plain file, three permission-only files and the open-password file. Only the plain one shrank — by 25.7 percent. The other four all failed with a message stating the file has encryption or permission protection that must be removed first, including the sample whose flags actually permit modifying and assembling. The session made zero non-GET requests, and the progress card read DONE next to a count of zero compressed files, a small interface mismatch the author notes.

The author's explanation, offered explicitly as a guess: a rewritten file must either be re-encrypted or written plain. Re-encrypting would mean rebuilding the owner's security setup without the owner password, and writing plain would quietly drop restrictions someone chose. Refusing every encrypted file is the one option that is easy to defend.

Why it matters

If you rely on PDF permission passwords to protect content, you are relying on reader courtesy, not cryptography. Any viewer that ignores the flags, or any library that leaves enforcement to the calling code, can copy, print and edit freely. Developers building PDF tooling face the same fork the compressor did. The author's advice is to decode P, show users what the file declares, and point them to the file's author for an unrestricted copy, rather than silently obeying or silently stripping. Acrobat, macOS Preview and the released Safari were not tested, so the picture for mainstream consumer viewers is incomplete — but the core lesson stands: the restriction is data, not a lock, and the reader decides.