Picture a client sending the contract PDF for a small freelance job. It opens straight away, with no password prompt, but the text won't copy into your notes, print does nothing, and the one tool you try says the file is encrypted. This hasn't happened to me with a real contract. I set it up as an experiment to see where that afternoon would go. I generated seven two-page placeholder PDFs that say "sample contract (placeholder text, test only)": one with no protection, five with only a permissions password, and one with an open password. Then I opened them in Chromium 149 (an open-source build) and Firefox 151.
The first thing I would check is whether the file asked for a password when it opened, because the answer points to two different problems.
This is what the open-password file looks like in Firefox 151. Nothing of the document shows behind the dialog. Chromium stopped at a password box too. Without that password you have no contract to read, so the only useful move is asking the sender for it. The other five protected files never showed a box like this. They had a complete encryption dictionary and the content really was encrypted, but the user password was empty, so every viewer opened them silently. A permissions password only states what the reader software should allow afterwards: printing, copying, editing.
Whether the software actually does that varies. With the same fully restricted file, Chromium's built-in viewer blocked copying (I could drag a blue selection, but nothing reached the clipboard) and blocked printing, yet it still let me draw on the page. Firefox 151 with default settings enforced none of the three. With its permission setting turned on, it hid the print button and greyed out the editing tools, while copying still went through. Files with the same permission bits behaved the same whether they used AES-256, RC4-128, or RC4-40. I don't read that as a tip for getting around a client's settings. I read it as a reason not to plan work around any one viewer's behaviour. A restriction that one program honours and another ignores won't give you a dependable editable copy, and it isn't dependable protection for the sender either.
Then I checked what a processing tool does with these files. The compressor I used was ImgIng's PDF compression (https://imging.ai/), with English versions of my own test files: one unprotected, two with only a permissions password, and one with an open password. The unprotected file went from 52 KB to 35 KB. All three encrypted files ended as "Failed 53 KB · This PDF is encrypted; remove protection first", including the one that only blocked copying and allowed editing. It didn't offer a password field, even for the open-password file. The page made 41 requests during the run and every one was a GET, so no file was posted anywhere. After the failures the progress card still said "All done", next to "0 file(s) compressed". The interface doesn't explain why it refuses. My guess, and it is only a guess, is that rewriting would force a decision about re-encrypting the file and honouring the owner's restrictions, and refusing avoids that.
So I would stop trying tools at that point. A freelancer's hour spent fighting a restricted file is an hour nobody pays for, and the proper fix sits with the person who made it. If the file opened without a password, I would ask the sender to re-export it from the original program without the restrictions, which they can do by entering the owner password they set, or to send the editable source, usually the .docx. If it asked for a password, I would ask for the password and nothing else. The message can be short: "The PDF opens fine, but it's set to block copying and editing, so I can't add my changes. Could you send the Word file, or export the PDF again without the restrictions? If you'd rather keep it locked, I'll send my changes as a list and you can apply them."
I include the last option because some senders lock the file on purpose. They want a review, not edits, and a list of changes lets the job continue without arguing about it.
My test has limits. The files were my own placeholders, so real contracts may use other permission combinations. I didn't test Acrobat Reader, macOS Preview, released Safari, or any phone app. In Chromium I only saw that drawing worked; I didn't save a modified file.
Next time a PDF opens but won't cooperate, note whether it asked for a password, then write the two-line message before trying another tool.
Top comments (0)