Password-protecting a PDF before emailing it, and why the "no printing" box isn't a lock

Bank statements, salary slips and ID scans get emailed around all the time. Putting a password on the PDF first is cheap insurance: if the mail lands in the wrong inbox or sits in a shared folder, the file is useless without the password. It only works if you know what the password actually protects, and PDF encryption has two passwords that do very different jobs.

Two passwords, two jobs

The open password (the spec calls it the user password). A reader won't show any page until you type it. This is the part that keeps a stranger out.

The owner password. It controls the permission flags: printing, copying text, editing, filling forms, and so on. Someone who opens the file with the open password gets the restricted version. Someone who opens it with the owner password gets everything.

The file is encrypted either way. The flags are different: they're a request written into the file, and it's up to the reader software to honour it. I'll show below what that means in practice.

Built-in ways to do it

You may not need anything new:

• Microsoft Word (Windows): File > Save As, choose PDF, click Options, and tick "Encrypt the document with a password".
• LibreOffice: File > Export as PDF, open the Security tab, and use Set Passwords. It asks for the open password and the permissions password separately.
• macOS Preview: recent versions have File > Edit Permissions, where you can require a password to open the document and set an owner password for the permissions.

Whatever you use, open the result afterwards and confirm it asks for the password before you delete the original.

From the command line with qpdf

qpdf is free and open source, and it's my go-to when I want to know exactly what's in the file. This sets a different open and owner password, uses 256-bit AES, and turns off printing and copying:

qpdf --encrypt --user-password=river-cobalt-42 --owner-password=Owner-only-9x \
  --bits=256 --print=none --extract=n -- statement.pdf statement-protected.pdf

Then check what you made:

qpdf --password=river-cobalt-42 --show-encryption statement-protected.pdf

On my test file that printed R = 6, Supplied password is user password, print high resolution: not allowed, extract for any purpose: not allowed, and AESv3 for streams, strings and files. R = 6 with AESv3 is the AES-256 handler from PDF 2.0, the strongest standard option a PDF has.

poppler's pdfinfo makes a good second check, because it won't touch the file without the password:

pdfinfo statement-protected.pdf
# Command Line Error: Incorrect password
pdfinfo -upw river-cobalt-42 statement-protected.pdf | grep Encrypted
# Encrypted: yes (print:no copy:no change:yes addNotes:yes algorithm:AES-256)

Why the "no printing" box isn't a lock

Here's the part that surprised me. With that same file and only the open password, two ordinary commands ignored the restrictions completely.

pdftotext pulled the text out, even though the file says copying isn't allowed:

pdftotext -upw river-cobalt-42 statement-protected.pdf - | head -2
# Account statement, test file
# Balance: 12,345.67

And qpdf wrote a fully decrypted copy with no restrictions at all:

qpdf --password=river-cobalt-42 --decrypt statement-protected.pdf plain.pdf
qpdf --show-encryption plain.pdf
# File is not encrypted

That isn't a bug in either tool. Once you have the open password, you can decrypt the content, and the flags are only a note asking the reader to behave. Acrobat and most mainstream viewers respect them. A script doesn't have to. So treat the permission flags as a guard against accidental editing or printing by a cooperative reader, not as a way to stop a determined recipient from copying something you've already let them read.

If you want the flags to mean anything, the owner password has to be different from the open password. When I encrypted the same file with both passwords set to the same string, --show-encryption reported Supplied password is owner password for the open password, which means anyone who can open the file holds the full set of rights.

Sending the password

The point of the password is lost if it travels in the same email as the file. Send it by another channel: a text message, a call, or a password you agreed earlier. For recurring documents, some banks and employers use a pattern built from your name and date of birth, which is convenient and also guessable by anyone who knows you. For files you protect yourself, use a long passphrase. AES-256 isn't the weak point; a short password is, because an attacker with the file can try guesses offline as fast as their hardware allows.

Gotcha: a blank owner password can mean no password at all

Leaving the owner password empty feels harmless, as if it just means "no extra restrictions". With 256-bit encryption it's worse than that. qpdf refuses outright:

qpdf: A PDF with a non-empty user password and an empty owner password
encrypted with a 256-bit key is insecure as it can be opened without a password.

I forced it with --allow-insecure to see, and the warning is accurate. pdfinfo opened the result with no password at all and printed Encrypted: yes (print:yes copy:yes ...), and pdftotext read the text straight out. A reader tries the empty string as the owner password, it matches, and the open password never gets asked for. If a tool lets you leave the owner password blank, check what it writes in its place, then test the output with pdfinfo before you send it.

I built ToolOcean, a set of browser-based file tools. Its password page encrypts with AES-256 (revision 6) in the browser tab, and when the owner password is left blank it stores a copy of the open password instead of an empty one, so the file still needs a password to open: https://toolocean.co/pdf-encrypt

Drafted with AI help, tested and checked by me.