PDF passwords and permissions: what protection really stops, and what it does not

A statement arrives from the bank and demands a password. A contract goes out with printing switched off, and the other side prints it anyway. A portal rejects your carefully protected application as an “invalid file”. All three come from the same place: PDF has two passwords that do very different jobs, and most of what is sold as “protection” is the weaker one asking nicely. By the end of this guide you will know which password actually encrypts a document, why the permission flags stop nobody, how to read a file’s encryption settings in one command, and how to protect, unlock and watermark a PDF in your browser.

Two passwords, two jobs

ISO 32000 defines a standard security handler with two passwords. The user password— Acrobat’s “Document Open Password” — must be typed before a reader shows anything. The owner password— the “Permissions Password” — is for whoever set the restrictions and may change or remove them. Either can be empty, both can be the same string, and the combination decides what you actually have.

The part that matters is what each password encrypts. Every string and stream in the file is encrypted with a file key that is unlocked by the user password. The owner password never touches the content; it only wraps a copy of the user password (revisions 2–4, entry /O) or of the file key itself (revision 6, entry /OE). So when the user password is empty — as it is in every “anyone can open it but nobody may print” file — the reader derives the full key from an empty string, decrypts every page, and then reads an integer telling it what it is supposed to refuse. The owner password only stands between the reader and rewriting that integer.

• Neither password: not encrypted; no /Encrypt entry in the trailer.
• Owner password only:opens for everyone; the print, copy and edit flags are a request. Most “secured” PDFs in circulation are this.
• User password only, or both the same string: genuinely encrypted; whoever knows the password has every right. This is what Protect PDF produces.
• Two different passwords: encrypted; user-password holders see the flags as a request, owner-password holders can drop them.

What the encryption dictionary says

Encryption is declared by an /Encrypt entry in the trailer. A file written by the Protect PDF tool carries a dictionary like this:

/Encrypt <<
  /Filter /Standard
  /V 5  /R 6  /Length 256
  /CF << /StdCF << /CFM /AESV3 /AuthEvent /DocOpen /Length 32 >> >>
  /StmF /StdCF  /StrF /StdCF
  /P -1
  /O <48 bytes>  /U <48 bytes>
  /OE <32 bytes>  /UE <32 bytes>
  /Perms <16 bytes>
>>

/V and /R name the algorithm generation, /Length the key size in bits, and /CFM /AESV3 means AES-256 in CBC mode. /O and /U validate the two passwords, /OE and /UE hold the file key wrapped under each of them, and /Perms is the permissions value encrypted with the file key so a cooperating reader can detect tampering with the flags. /P itself sits in the file in plain text — which is fine, because it never protected anything.

The permissions integer /P is a signed 32-bit bitfield. Bit 3 allows printing, bit 4 modifying, bit 5 copying text and graphics, bit 6 annotating and filling forms, bit 9 filling forms only, bit 10 extracting text for accessibility, bit 11 assembling pages and bit 12 high-resolution printing. -1 is everything allowed; -3392 is everything denied except accessibility extraction.

Why the permission flags are a suggestion

Once a viewer holds the file key it holds the plaintext of every page, and nothing in the format can stop it printing, copying or editing that plaintext. Whether the /Pbits are honoured is a policy decision by the viewer’s authors. Acrobat and Reader honour them: File → Properties → Security lists “Printing: Not Allowed” and greys out the menu item. Firefox’s built-in viewer has a preference, pdfjs.enablePermissions, that defaults to false — it ignores the flags unless the user switches them on. Libraries and command-line tools mostly do the same, because from their side there is nothing to enforce: the bytes are already decrypted in memory.

Even a cooperating viewer cannot stop the operating system: a screenshot captures the screen, “Print to PDF” makes a clean copy wherever printing is allowed, and a phone camera defeats everything. The flags are a courtesy notice for well-behaved software. The only thing PDF can genuinely stop is opening, and only with a non-empty user password under AES-256; everything downstream of opening runs on trust.

How to tell which case you are in

If a viewer prompts before showing anything — Firefox says “Enter the password to open this PDF file.”, Chrome says “This document is password protected. Please enter a password.” — the file has a user password. If it opens silently but Acrobat’s Security tab reports “Security Method: Password Security” with items marked “Not Allowed”, it has only an owner password. On a command line, qpdf tells you everything at once:

$ qpdf --show-encryption statement.pdf
R = 6
P = -3392
User password =
Supplied password is user password
extract for accessibility: allowed
extract for any purpose: not allowed
print low resolution: not allowed
print high resolution: not allowed
modify document assembly: not allowed
modify forms: not allowed
modify annotations: not allowed
modify other: not allowed
modify anything: not allowed
stream encryption method: AESv3
string encryption method: AESv3
file encryption method: AESv3

Read it from the top. R = 6 is AES-256 revision 6; R = 2 would be 40-bit RC4 and worth re-protecting. An empty User password = line on a file opened without --password means anyone can open it, so the restrictions below are decorative. For scripts, qpdf --is-encrypted file.pdf exits 0 when an /Encrypt entry exists and 2 when it does not; qpdf --requires-password file.pdf exits 0 when a password is needed to open the file, 2 when it opens without one (even if encrypted) and 3 when it is not encrypted at all. Poppler’s pdfinfo puts the same facts on one line: Encrypted: yes (print:no copy:no change:no addNotes:no algorithm:AES-256). With no tools to hand, search the file in a text editor for /Encrypt; an unencrypted PDF has no such entry.

Matching the protection to the threat

“Protect this PDF” is not one problem. Name the thing you are worried about first, because each row below needs something different, and for two of them a password is counterproductive.

Revoking a document after sending it, limiting it to named people or making it expire is rights management — Adobe’s document security server, Microsoft’s information protection — where the viewer contacts a licence server on every open. Plain PDF cannot do it, it works only in viewers that support it, and it still loses to a camera. For the interception row, a transfer that never touches a server is often simpler than a password; see sending files directly between devices.

The password is the whole security

Nobody attacks AES-256 itself; they guess the password, and revision 6 exists to make each guess cost more CPU time. That helps only if there are many candidates to try. A date of birth in DDMMYYYY form has about 36,500 possible values across a century — roughly 15 bits — and a laptop tries all of them in under a second, hardened hash or not. Four random words from a 7,776-word list are about 52 bits; six words about 78; sixteen random printable characters about 105. The arithmetic, and how attackers order their guesses, is in what makes a password strong.

Two rules follow. Never put the password in the same email as the attachment; agree it by phone, send it over a messenger, or reuse one exchanged in person. And record it in a password manager the moment you set it, because a revision 6 file with a forgotten strong password is gone.

Protecting, unlocking and watermarking in the browser

The three tools below cover the three operations, and because they run inside the tab the unprotected intermediate copy never exists anywhere but your own device.

Protect PDF

Protect PDF takes one .pdfand a password typed twice; mismatched entries stop with “The passwords do not match.” It then runs a WebAssembly build of qpdf with --encrypt password password 256, which writes AES-256 revision 6 (/V 5 /R 6, /CFM /AESV3) with the same string as user and owner password. It sets no permission flags, deliberately: anyone who can open the result can do anything with it, and the tool cannot produce a permissions-only file. The download is original_protected.pdf, confirmed by “Encrypted with AES-256 — download started. Keep the password safe: it cannot be recovered.” If you see “Could not protect this PDF. It may be corrupted or already encrypted.”, the input is usually already encrypted: unlock it first.

Unlock PDF

Unlock PDF is the reverse: one .pdf plus its current password (the button stays disabled until you type one), run through qpdf --password=… --decrypt. qpdf tries the string as the owner password first and then as the user password, so either works; original_unlocked.pdf has the /Encryptentry removed and every stream in the clear, with content, fonts and layout untouched. A rejected password produces “Wrong password — this tool removes protection only from PDFs you can already open.” That sentence is the whole policy: a convenience for files you are entitled to open, not a cracker — and no browser tool could crack a revision 6 file with a decent password.

Watermark PDF

Watermark PDF accepts one or several PDFs, a text string (default CONFIDENTIAL) and an opacity of Light, Medium or Strong — 0.15, 0.25 or 0.45. Using pdf-lib it draws the text in Helvetica Bold at 50 pt, 50% grey, rotated 45° and centred on every page. That makes it an ordinary text object in the page content stream: no annotation to delete, no layer to hide, and a text extraction of the result contains the word on every page. One file downloads as original_watermarked.pdf; several arrive as watermarked.zip. pdf-lib cannot edit encrypted pages, so an encrypted input fails with “Could not watermark. The file may be corrupted or password-protected.” — the order for a document that needs both is unlock, watermark, then protect, with encryption always last.

Workflows that come up every week

Bank statements and salary slips

Banks and payroll systems protect emailed statements with a password built from data you already know — a date of birth, part of an account number, the first letters of a name: a 15-to-25-bit secret guarding your balance, retyped every time you open the file. Unlock it once, file the clean copy in an encrypted folder or vault, and if you need a protected copy, re-protect it with a password you chose.

Contracts, e-signatures and portals

E-signature services and most upload portals reject encrypted PDFs, sometimes with an error that never mentions encryption. Run qpdf --is-encryptedon anything you are about to upload, or open it and look for a prompt, and remove protection first; the service’s login and HTTPS already do the job. Keep a clean master, stamp DRAFTon the copy that goes round for comments, and send the master to be signed. Never run a signed PDF through Protect PDF afterwards: encryption rewrites every object, the signature’s byte range no longer matches, and viewers report the signature as invalid. If a size limit also applies, unlock first and shrink second — see reducing PDF file size.

Archiving

Every part of the PDF/A archival standard (ISO 19005) forbids the /Encrypt entry, because an archive is meant to outlive the person who knew the password. Store archived documents unencrypted inside an encrypted disk image, vault or backup, where one key protects everything and is itself backed up.

Common mistakes

• Relying on “no copying”. If the file opens without a prompt, every recipient already has the plaintext; the flag is an instruction to Acrobat, not to the world.
• Protecting the only copy. The tool warns that the password cannot be recovered, and it means it. Keep the unprotected original somewhere safe and put the password in a manager before sending anything.
• Trusting an old tool’s output. Older office suites and PDF printers still write RC4 or AES-128 revision 4. Check with qpdf --show-encryption; anything below R = 6 deserves an unlock-and-reprotect pass.
• Encrypting documents that other software has to read.A user-password file cannot be indexed by desktop search, previewed as a thumbnail, OCR’d or merged. On this site the tools that open PDFs with pdf.js fail with a PasswordException on such a file and the watermark tool refuses it; OCR needs the clean file too.
• Assuming a watermark is permanent.Acrobat’s own “Add Watermark” can be removed from the same menu; the one this site draws is page content, but an editor can still delete a text object. Where it must survive editing, render the pages with PDF to JPG and rebuild with Image to PDF, accepting that the result has no selectable text.