A PDF can carry two passwords, and only one of them locks anything. The open password (the spec calls it the user password) encrypts the pages so nothing can be read without it. The permissions password (the owner password) sets flags such as “no printing” and “no copying”, and a file that has only this one opens for anybody, with no prompt at all. We made both kinds and opened them in ten readers and libraries on 24 September 2026. The restrictions held in one of them, and only for copying.
The spec says so itself
ISO 32000, the PDF standard, is blunt about it. The 2008 edition (ISO 32000-1, §7.6.3.1) says that once a document has been opened and decrypted, a reader “technically has access to the entire contents of the document. There is nothing inherent in PDF encryption that enforces the document permissions specified in the encryption dictionary.” Readers are told they “shall respect the intent of the document creator”, which is a request to the people who write PDF software, not a lock. The current edition, ISO 32000-2 (PDF 2.0), covers encryption in §7.6 and standardises the AES-256 method (revision 6) our tool uses by default. The permission flags still sit in the same encryption dictionary, next to the key.
A file protected with permissions only is still encrypted, but with an empty open password, so every reader can derive the key. qpdf, the tool we build our password pages on, says as much in its own help text: “Not all readers respect all restrictions.”
What ten readers did with a restricted file
We took our own three-page test letter (an invented name, email address, card number and phone number), and encrypted it three ways with qpdf 12.2: permissions only with AES-256, permissions only with AES-128, and permissions only with the old 40-bit RC4 method. Each file forbids printing, copying and changes. A fourth copy got an open password as well. Then we opened each one without typing any password.
| Reader | Opened it | Text came out | What it did with the restrictions |
|---|---|---|---|
| Chromium 153 built-in viewer | Yes | No: select-all then copy left the clipboard unchanged | Blocked copying. The print button stayed visible and clickable |
| PDFium 153 (Chromium’s engine, as a library) | Yes | Yes, through its text API | Reported print: no, copy: no, and handed the text over anyway |
| pdf.js 4.10 (draws pages on this site) | Yes | Yes | Reported the flags when asked, ignored them |
| macOS 27 PDFKit and Core Graphics | Yes | Yes, through PDFKit | Reported allowsPrinting and allowsCopying as false, returned the text |
| qpdf 12.2 | Yes | n/a | Wrote an unrestricted copy with qpdf --decrypt and no password |
| pikepdf 10.13 (libqpdf 12.3) | Yes | n/a | Reported the flags, saved an unencrypted copy by default |
| pypdf 6.19 | Yes | Yes | Accepted an empty password as the open password |
| pdfminer.six 20260107 | Yes | Yes | None |
| pdf-lib 1.17 (edits PDFs on this site) | No | No | Refuses every encrypted file, restricted or not |
| ExifTool 13.55 | Reads details only | n/a | Listed the encryption (Standard V5.6, 256-bit) and what is allowed |
The Chromium result is the interesting one. Its viewer let us select the whole page, highlighted and all, but the copy produced nothing, so the restriction did something there. The same engine loaded as a library gave the text straight back, and it reported the very flags it was ignoring. That pattern repeats: pdf.js, PDFKit and pikepdf all read the flags correctly and left it to whoever wrote the app to act on them. A restriction is only as strong as the app the other person happens to open the file in.
The file with an open password was the opposite story. Chromium’s viewer showed a “Password required” box and nothing else; PDFium, pikepdf and qpdf reported an invalid password; PDFKit reported the document locked; pypdf and pdfminer raised password errors; pdf.js and pdf-lib refused it. ExifTool could still list the encryption method, and that was all anyone got without the password.
So which password should you set?
If the aim is that nobody without the password reads the document, set an open password and nothing else matters much. With AES-256 the only way in without it is guessing, so length is what protects you: a long passphrase, not a word with a number on the end.
Print and copy restrictions are worth setting only as a signal (“please don’t print this”) to people who will see it in a well-behaved viewer. Anyone who wants the text of a restricted file can have it with free software in seconds, and some of that software is on this site: pdf.js, which our PDF to text tool uses, read the restricted letter without complaint. Our Password-protect tool therefore keeps restrictions behind a “Restrictions and strength” section and says in the form that most readers ignore them.
Our Unlock tool goes the other way on purpose. qpdf could lift the restrictions from an owner-only file without any password, as the table shows, but Unlock only removes them when you type the permissions password they were set with. It never guesses. The restriction is the author’s request, and if the file is yours you have the password.
To add a password, use Password-protect PDF; to take one off a file of yours, Unlock PDF. Both run on your device. If what you need is to hide part of a page from people who will get the file, a password is the wrong tool: see why black boxes don’t redact.
Sources
- ISO 32000-1:2008 (PDF 1.7), Adobe’s public copy, §7.6.3.1
- ISO 32000-2:2020, Document management: Portable document format, Part 2 (PDF 2.0)
- qpdf documentation (the quoted line is from qpdf --help=encryption, version 12.2)
- pdf.js, the PDF renderer used on this site
- pdf-lib, the PDF editing library used on this site
- pypdfium2 (PDFium bindings used for the PDFium row)