Password-protecting a PDF

A payslip, a contract, a bank statement: the file goes out by email and then sits somewhere indefinitely — in an inbox, on a company server, in an automatic backup. The password is the only protection that travels with the PDF, wherever it gets copied. But you have to set the right one: the format offers two, and one of them protects almost nothing.

Two passwords, two very different levels of protection

The PDF specification provides for two separate passwords, which software interfaces routinely lump together under the single word “protect”.

• The user password, also called the “open” password: this is the one that locks access to the content. Without it, the reading software can display nothing at all — not the text, not the images, not the document’s attachments.
• The owner password, known as the “permissions” password: the document opens normally, but it carries flags that forbid printing, copying text, extracting pages or adding annotations.

The second is a convention, not a lock. The restrictions are written into the file, and it is up to the reading software to decide whether to honour them. Plenty of viewers — mobile readers and command-line libraries in particular — ignore them outright. A PDF “protected against copying” is therefore very often perfectly copyable.

The practical conclusion: if confidentiality is what is at stake, the open password is the one to set, and it is the only one that really counts. That is what the PDF protection tool does: you drop the file in, you type the password, you get back an encrypted PDF that will not open without it.

What the encryption covers, and what it leaves exposed

Encrypted PDFs have used, in turn, RC4 at 40 and then 128 bits (older files, broadly anything from before 2006), then AES-128 from Acrobat 7 onwards, and finally AES-256, which arrived with Acrobat 9 in 2008 and was standardised in its current form by PDF 2.0. The RC4 variants are now regarded as broken or fragile; AES-128 and AES-256, by contrast, are beyond the reach of a direct attack.

But the algorithm is almost never the weak link. An AES-256 file locked with “Invoice2024” falls in seconds to a dictionary search: it is the password that sets the real level of security, not the box ticked in the software.

Three things stay visible even on a properly encrypted PDF:

• The file name. It is never encrypted. “redundancy-settlement-smith.pdf” tells the whole story before the password prompt even appears.
• The metadata, sometimes. The standard allows the metadata block to be left in the clear so that indexing engines keep working; depending on the tool used, the title, the author or the originating software may stay readable.
• The file size and the page count. Encryption applies to the content streams, not to the structure of the document.

And above all, a password is no substitute for redaction. Dropping a black rectangle over an account number erases nothing: the text is still in the file, underneath the rectangle, and it comes straight back out on the first copy or the first extraction. Data that must not be read has to be removed from the document, not covered up.

A password that holds, and that reaches the other end

Four rules that make a genuine difference:

• Length before complexity. Four everyday words picked at random hold up better than “P@ssw0rd!”. Reckon on 12 characters as a minimum, 16 if the document travels beyond a single person.
• Nothing taken from the document. The client’s name, the case number, today’s date or the invoice reference are the first things anyone trying to open the file will type.
• A different channel for the password. Sending the PDF and its password in the same email undoes all the work. File by email; key by text message, over the phone or through encrypted messaging.
• Nothing outside ASCII. Accented characters and unusual symbols are encoded differently from one reader to the next; a password containing “£” or “é” can quietly stop working as the file moves between programs. Stick to a-z, A-Z, 0-9 and simple punctuation.

For generating one, a password generator avoids the natural bias that keeps landing on the same handful of structures. Then file the key in a password manager: an encrypted PDF whose password has been lost is lost for good. There is no recovery procedure — which is exactly what the encryption is there for.

The order of operations matters

Encryption has to be the last step. A protected PDF refuses most later processing: merging, splitting, rotating and compressing either fail outright or demand the password at every pass. So finish the document first — assemble the parts, turn the pages the right way up, bring the file size down with PDF compression if you need to send it as an attachment — and encrypt only at the very end.

Once it is protected, always run a check: close the file, reopen it, confirm that it does ask for the password, and test it if you can in a reader other than the one used to create it. Thirty seconds that save you from sending a document the recipient cannot open — or, worse, a document that opens without asking for anything.

The most common sticking points

“The file is already protected”

You cannot stack two layers of encryption. If the PDF already carries a password, it has to be taken off first with the unlocking tool — assuming, of course, that you know that password and are entitled to act on the document — and the new one applied afterwards.

The recipient cannot open it

The previews built into webmail and messaging apps do not always handle encrypted PDFs: the preview shows a blank page or a generic error. Ask the recipient to download the file and open it in a proper PDF reader before concluding that the password is at fault.

The platform refuses the upload

Plenty of portals — government services, banks, job application systems, tender submissions — reject encrypted PDFs because their automated processing chain cannot read them. Check the instructions before sending, even if that means uploading an unprotected version over a channel that is already secure.

The document carries an electronic signature

Encrypting a document that has already been signed can make verification fail in some checking tools. If the signature carries legal weight, have the recipient test the final file before you treat the job as done.

The PDF is a scan

A password protects access, not legibility. A scanned document with no text layer is still a series of images once it is unlocked: no search, no copy and paste. If the recipient needs to search inside it, it has to go through OCR before being encrypted.

When a password is not the right answer

Three situations where something else works better:

• Wide distribution of a document you only want to discourage people from reusing (a price list, a portfolio, a proof): the password becomes unmanageable the moment it has to be passed to thirty people, and it does not survive the first leak. A visible watermark does not stop anyone reading the file, but it does discourage reuse — which is exactly the point here.
• Long-term archiving. Encrypted documents reopened in ten years’ time, with no record of the password anywhere, are documents lost for good. For archives, encrypt the medium or the container rather than each file on its own.
• Sharing you want to be able to take back. An expiring, revocable link leaves a record of who downloaded what, and it can be cut off with one click. An encrypted PDF, once it has gone, cannot be called back.

For everything else — the attachment that should only be read by the person it was sent to — the open password remains the simplest and most universal answer, because it depends on no third-party service to work. PDF protection runs on Convertu’s servers, uploaded files are deleted after an hour, and one conversion a day is free with no sign-up; beyond that, the €7-a-year subscription lifts the limit across every server-side tool.