Password-protect a PDF without uploading it

Encrypting, adding a password and restricting printing are three different things

All three get called «protecting the PDF», and people who confuse them end up trusting the wrong one. Encryption is the maths that makes the content unreadable. The password is the key to that lock, and it is the only one of the three that actually defends the document. Printing and copying permissions are flags written into the file: a request addressed to the programs that open it, not a lock.

1. 1Encryption: the content of the file becomes unreadable without the right key.
2. 2Open password: without it the document does not open, and there is no way to read it.
3. 3Permissions: flags written into the file, which each reader decides whether to honour. None of the readers we tested enforces them.
4. 4If something has to stay secret, it must sit behind the password, not behind a permission flag.

What is actually applied to your file

Not «some protection»: the engine is qpdf 12.2.0 compiled to WebAssembly, and it writes AES-256 encryption at revision 6, the one the PDF format uses for 256-bit keys. Streams and strings in the document are encrypted with AESv3. Your original file is not modified: what you download is a protected copy.

1. 1AES 256-bit encryption, format revision 6, over streams and strings.
2. 2The open password is the one you chose: it is sent nowhere and lands in no storage that outlives the tab. While you type it lives in the field and in the page memory, and during encryption it passes through the engine memory: that is what using it means.
3. 3The password that governs permissions is generated at random on the spot, is different from yours and is never shown: without it, the printing and copying restrictions would mean nothing even to someone holding only the open key.
4. 4The protected file is reopened by the engine before it is handed to you: if it would not open with your password, you would not get it at all.

Choosing a password that holds

AES-256 faithfully protects any password, weak ones included: that is the part half the internet forgets to mention. A four-character password is exhausted in seconds, and the algorithm can do nothing about it. That is why the minimum here is twelve characters, and why the advice is a phrase rather than a word.

1. 1A phrase of several words is easier to remember than one word with symbols in it, and harder to guess.
2. 2Unique to this document: if it is shared with other services, the document is worth as much as the weakest of them.
3. 3The PDF format stops at 127 bytes, and accented letters and emoji count as more than one byte each, so the count is shown while you type.
4. 4Keep it in a password manager, not in the same email as the attachment.

Send the password through another channel

Sending the file and the password in the same message is leaving the key in the lock: whoever intercepts the email, or receives it by mistake, holds both halves. The document travels by email, the password goes by voice, phone or a separate message. The same applies inside one office: a colleague's mailbox is an archive that lasts for years.

1. 1Document and password on two different channels, every time.
2. 2Better still if the password is agreed in advance rather than sent afterwards.
3. 3If the recipient loses it there is no recovery: keep the unprotected original somewhere safe.

Who uses this, and with what document in hand

Law firms

A filing or an expert report going to a colleague: the attachment travels encrypted, the password is agreed by phone.

Accountants and advisers

Statements, filings and company records sent by email, where the attachment stays archived for years.

HR teams

Contracts, payslips and reviews: documents that should not stay readable inside a shared mailbox.

Admin and back office

Invoices and letters holding third-party data, sent to addresses typed by hand and sometimes mistyped.

Anyone sending a personal attachment

A medical report, an ID document, a tenancy agreement: one password costs ten seconds.

What we claim, and how you can check it

The document is never uploaded

Open developer tools, Network tab, and protect a file: no request carries the PDF out.

The password is neither sent nor stored

In the same Network tab it appears in no request. Under Storage it appears in neither localStorage nor cookies. It sits in the field while you type it, and goes as soon as the protected file is ready or you switch document.

The encryption really is AES-256

If you have qpdf or Poppler: qpdf --show-encryption reports R = 6 and AESv3, and pdfinfo says «algorithm:AES-256». One caveat about pdfinfo: that command's -upw option stops at 32 bytes, so with a longer passphrase it answers «Incorrect password» even though the file is fine. It is a limit of the command, not of the document: called directly, the Poppler library opens the same file, and qpdf --password= has no such limit.

It does not open without the password

Try opening the downloaded file in another PDF reader and typing nothing: it asks for the password and shows no content.

The limits, said before you run into them

These are the points where password protection does not do what many people expect. Knowing them is part of the job.

A weak password stays weak

The encryption is strong, the key is not. If the password can be guessed, nothing has to be broken: it just gets typed in.

Forget it and the document stays shut

SecureLocalSuite does not send the password to its servers or retain it in persistent storage, so it cannot recover it. Keep the unprotected original: from that you can always make a fresh copy with a different password.

The password lives in the page for as long as it is needed

It sits in the field while you type it and passes through the engine memory during encryption: without that it could not be used at all. It is sent nowhere and lands in no storage that outlives the tab. The field is cleared after a successful delivery and when you switch document; after an error it stays, so you can retry without retyping it. As in any program written in JavaScript, we cannot guarantee every copy of the string leaves memory the instant you are done with it.

Printing and copying are not absolute bans

The flag is written into the file and read back correctly, but honouring it is up to whichever program opens the document. Measured on the produced file: Poppler, Ghostscript and pdf.js all read the restriction and then extract the text anyway for anyone holding the password. They are requests to readers, not a barrier.

An already encrypted PDF cannot be re-encrypted

It has to be opened with its own password first. The tool says so and stops, instead of handing you an empty file.

Very old readers cannot open AES-256

Revision 6 arrived with recent versions of the format: a program from fifteen years ago may not recognise it.

Protection does not remove metadata

Author, software and dates stay in the document. Removing them is the Metadata tool, which is a different job.

Before or after you add the password

• Redact sensitive data: for parts that must not be read even by someone holding the password
• Remove metadata: author, software and dates stay in the file even after encryption
• PDF privacy check: what can still be recovered from a document before you send it
• How local processing works, and how to verify it yourself