I used to think "encrypted PDF" and "password-protected PDF" meant the same thing. Then I made a handful of test PDFs for a side project and ended up with a file that opened instantly in my browser, no prompt at all, while a compression tool refused it for being encrypted. It took me a while to accept that both were telling the truth, because a PDF can carry two different passwords and only one of them is about opening the file.
All my samples are two-page placeholder documents I generated with a script, titled "Sample Agreement (placeholder text, for testing only)". One has no encryption. Five have only a permission password, meaning the user password is empty and an owner password sets the restrictions. One has an open password. I inspected them with pypdf and PyMuPDF, then opened them in the viewers built into Chromium 149 (an open-source build) and Firefox 151.
| Sample type | Opens without a password? | Has an /Encrypt dictionary? | What it restricts |
|---|---|---|---|
| No encryption | Yes | No | Nothing |
| Permission password only | Yes, with no prompt or warning | Yes | Printing, copying, editing, per its permission flags |
| Open password | No, the viewer asks first | Yes | Opening, then the same flags once it's open |
The middle row is what had confused me. Those files really are encrypted. They carry a full /Encrypt dictionary, and their content streams are AES or RC4 encrypted. The user password is just empty, so any reader decrypts them with that empty password and shows the pages, which is why nothing asked me for anything. The libraries even word it differently. pypdf's is_encrypted returned True for a permission-only file. PyMuPDF's is_encrypted returned False for the same file, because there it means "still locked right now", yet its metadata listed "Standard V5 R6 256-bit AES". One boolean won't tell you which kind of file you're holding.
So what does a permission password actually stop? In Chromium's viewer I dragged across four lines of a copy-restricted file, pressed Cmd+C and pasted into a text box. The selection looked completely normal, and nothing came out.
Both panels are an English copy of my placeholder layout in Chromium's built-in viewer, unencrypted on the left and copy-restricted on the right. Look at the blue highlight first. It shows up on both sides, so selecting text works either way. Then look at the paste boxes underneath. The left one holds the four lines. The right one, inside the red frame, still shows "Paste here" because nothing reached the clipboard. That empty box is the only difference between the two panels.
Chromium also did nothing when I clicked print on the samples that forbid printing. It did let me draw on all seven samples, including the ones that forbid annotations. Firefox 151 on default settings didn't enforce print, copy or edit on any of them. The algorithm made no difference either. Files with the same flags behaved identically whether they used AES-256, RC4-128 or RC4-40. A permission password is a request written into the file, and each reader decides how much of it to honour. Chromium did block copying and printing, so the request does something. It still depends on the reader agreeing to it.
An open password works differently, because the reader stops you before a single page appears.
This is Firefox 151 opening my open-password sample. Behind "Enter the password to open this PDF file." there is only a grey page, and Chromium shows its own dialog for the same file. Without that password you get no content at all, which is what most people picture when they hear "encrypted". Even after I entered the correct open password, Chromium still blocked copying and printing. The permission flags simply apply on top.
For the compression part I used ImgIng's PDF compressor (https://imging.ai/) in its Chinese interface, feeding it my own permission-only and open-password test files. Its page says processing stays on the device, and I saw zero non-GET requests during the run. The unencrypted sample shrank by 25.7%. Every encrypted one failed with the same message, which I'd translate as "This PDF has encryption or permission protection and needs that protection removed first." That included a file whose flags allow modifying, and the open-password file never got a password prompt. The interface doesn't say why. My guess, and it's only a guess, is that rewriting the file would mean dealing with the owner's restrictions.
I didn't test Acrobat, macOS Preview or the released Safari, so I can't speak for them. For the viewers I did test, this is the check I now run first when a PDF opens fine and a tool still calls it encrypted. If the viewer asks for a password on open, you need that password from whoever sent the file. If it opens with no prompt, it's permission-only, and the clean fix is to ask the author for an unrestricted version or the source document. If the file is yours and you remember the owner password, open it in the software that made it, enter the owner password there and export a new copy.
Top comments (0)