A PDF that opens without asking for anything can still be encrypted. I ran into it with a file I had made myself: a tool called it "encrypted" while every viewer I had opened it instantly. The file only had a permission password. The user password was empty, so any reader unlocks it silently, and the permission flags inside say what you may not do: print, copy, edit. Whether those flags mean anything depends on who reads the file. So I made seven two-page placeholder PDFs myself, a fake "Sample Agreement" with no real content, and fed them to five different handlers to see who actually enforces what.
I tried the same files in five handlers
One file had no encryption at all. Five had a permission password only, with different ciphers (AES-256, AES-128, RC4-128 and RC4-40) and different flags: some denied everything, one denied only copying, one denied only printing. The last one had a real open password. The handlers were the built-in viewers of Chromium 149 (an open-source build) and Firefox 151, Firefox again with its pdfjs.enablePermissions setting turned on, pdf.js 6.3 used as a library in a page, and PyMuPDF 1.26 as a processing library. Here is the whole result for the file that denies everything.
Read it row by row. Green means the handler refused the action, orange means the action still worked, grey means the handler just passed the flags to the calling code. No two viewer rows match.
Chromium still allowed drawing
Out of the box, Chromium enforced more than anything else I tried, and still not everything. Dragging across the text gave the normal blue highlight, which made me think copying worked. Pasting into a text box gave me nothing. The unencrypted twin pasted all four lines. Printing was blocked in a quieter way: the print button stayed visible, and on the four files that deny printing, clicking it did nothing. I never saw a real print dialog in this build, so "blocked" here means the click had no effect. The part that surprised me was drawing. All seven files, including the ones that deny annotation, let me enter drawing mode, leave a stroke and light up the undo button. I did not try saving the result.
Firefox enforced nothing by default
With default settings, Firefox 151 printed, copied and opened every edit tool on all seven files. After I turned on pdfjs.enablePermissions, it hid the print button on the files that deny printing and greyed out the edit tools on the files that deny editing. Copying still worked, even on the file whose only restriction was "no copying". The toolbar change is easy to see side by side.
The cipher changed nothing
I expected RC4 versus AES to matter somewhere. It didn't. The AES-256, RC4-128 and RC4-40 files carry the same flags and behaved identically in Chromium and in both Firefox modes. Only the flags changed the outcome. The open-password file is a different animal: both viewers stopped at a password prompt, and after I typed the password, Chromium still refused copying and printing, because the flags apply after opening too.
Processing tools have to pick a side here too. The compressor I used was the PDF one on ImgIng, with my permission-only and open-password test files as input. It processes PDFs on the device, and my run made zero non-GET requests. Every encrypted file I gave it failed with the same message: 这份 PDF 有加密或权限保护，需要先解除保护 ("this PDF has encryption or permission protection; remove the protection first"). The file that only denied copying failed as well. The interface doesn't say why it refuses, and oddly the progress card still read "全部完成" (all done) with zero files compressed. I tested the Chinese version of the site, so that's where the quoted text comes from.
My takeaway after all this is modest. A permission password is a request that each reader decides how to honour, and the answers differ a lot. If you send PDFs, don't treat the flags as a guarantee, since the same file was copy-protected in one viewer and not in the other. If you receive one and need an editable copy, ask the author for a version without restrictions, or, if the file is yours and you remember the owner password, re-export it from the software that created it. I didn't test Acrobat, macOS Preview or release Safari, so check those yourself before you rely on them.
Top comments (0)