You export the document, you open it once to be sure, and it looks exactly right. Then you drop it into the portal — the court’s e-filing system, the grant site, the job application — and it comes straight back: this PDF is secured and cannot be accepted. You never set a password. You never clicked anything that said “protect.” As far as you knew, it was just a file. But the machine on the far end can see something you can’t, and it has decided your finished document is locked.
The unsettling part isn’t the rejection. It’s that the lock was already there, and nothing you did put it on. You inherited it.
Two locks, and only one of them announces itself
A PDF can carry two different kinds of password, and they do very different jobs. The first is the open password — the one everybody pictures. Set it, and the file won’t even open without the password typed in. That lock announces itself the instant anyone tries to look; there’s no mistaking it, and no way to send it somewhere by accident.
The second is quieter, and it’s the one that bounces filings. It’s the owner password, also called the permissions password. It doesn’t stop the file from opening. It sits on the actions you can take once it’s open — printing, copying text, editing, extracting a page — and switches them off one by one. Open a file locked this way and nothing looks wrong. It renders, it scrolls, maybe it even prints. The restrictions live in the file’s plumbing, and a normal reader honors them without saying a word.
Here’s the trap that makes it invisible: a PDF can be encrypted with an owner password that is the empty string. The encryption is switched on, the permission flags are set — copying: not allowed, editing: not allowed — but there is no password to type, because the password is nothing at all. Nobody guarded the file on purpose. A default did it, and left the door with a lock but no key and no sign.
The file isn’t broken. It’s carrying a rule someone else set and forgot to mention.
Where the lock comes from
Once you know to look, the sources are everywhere, and none of them ask. Office scanners routinely stamp a permissions lock onto everything they send, because the fleet was configured that way years ago and nobody remembers. “Secure” or “final” export presets in document tools flip encryption on as a courtesy. A bank statement, a signed contract, a licensed template, a report you downloaded from a vendor portal — many arrive already protected, and when you drop one into your own document or re-export it, the lock can ride along.
You didn’t choose any of it. You opened a file that looked ordinary, did your work, saved, and the encryption dictionary was there the whole time — copied forward from something upstream you never inspected, because why would you? It opened fine.
Why the machine on the far end refuses it
A person reading your PDF would never notice the lock. But the far end usually isn’t a person — it’s a pipeline. Court e-filing systems reject encrypted PDFs outright, because they need to stamp a header onto every page and they can’t write to a file that forbids editing. Grant and application portals run the text through parsers and plagiarism checks; an encrypted file yields nothing to read. Resume systems extract fields. Redaction and OCR tools rewrite the page. Archival validators demand the file be fully inspectable. Every one of these needs to touch the bytes, and a permissions lock is precisely a note that says: you may not.
So the file fails — not because anything in your document is wrong, but because a flag buried in its structure tells every automatic reader to keep out. And the error you get back is almost never honest about it. “Upload failed.” “Invalid file.” “Could not process.” The one word that would actually help — encrypted — is the word the portal keeps to itself.
Reading the lock before the gate does
This is the kind of failure Preflight exists to catch: real, consequential, and
completely invisible in the everyday view of the file. Preflight doesn’t open your PDF the way a
reader does and trust what it’s shown. It reads the file’s own encryption dictionary directly —
the /Encrypt entry and the permission bits beneath it — the same structure the portal is about to
consult. If a lock is there, it says so, in plain words: this file is encrypted; copying is
disabled; editing is disabled; here is why the destination will turn it away.
That alone changes the moment. Instead of a useless “upload failed” at the finish line, you learn what’s wrong while you can still fix it, and you learn it in language that matches what the far end actually objects to.
And then, if the file is yours, Preflight can clear the lock — write a clean, unencrypted copy with the permission flags gone and the text readable again. It does this the way it does everything else: on a copy, never the original. Your protected file stays exactly as it was, byte for byte, in case that lock was there for a reason you do want to keep. What you carry to the portal is a new file that has nothing to hide and nothing to refuse.
The lock you can’t see is still a decision
It’s tempting to treat a locked file as a broken one — something went wrong, start over. But the file isn’t damaged. It’s doing exactly what it was told, by a scanner or a preset or a download that made a choice on your behalf and never surfaced it. The whole problem is that the decision was made silently, and the first time anyone tells you is the gate that won’t open.
Preflight’s job is to be the one that tells you first. It reads the rule before the portal does, names it while you can still act, and hands you a file the gate has no reason to refuse — without ever unsetting a lock you meant to keep. The lock nobody set is still a lock. You just deserve to see it before it’s the reason your finished work bounces.