Encrypt a PDF properly before you attach it to an email

Email attachments travel further than people expect. A single message can be copied to the sender's outbox, two mail servers, a spam filter, an archiving appliance, a mobile device, and a backup — before the recipient forwards it to one more person "for context". Encrypting the attachment does not stop any of that copying. It just means the copies are useless without the key.

Pick the right encryption revision

PDF encryption has accumulated several generations, and a tool that offers you the choice is not being helpful by defaulting to the oldest one.

Revision	Status	When to use it
40-bit RC4	Obsolete	Only if a specific ancient reader demands it
128-bit RC4	Superseded	Legacy compatibility, not protection
128-bit AES	Acceptable	Older readers that cannot do AES-256
256-bit AES	Current	The default choice for anything that matters

The PDF encryption tool applies AES-256 and does the key derivation in the browser, so the plaintext document is never transmitted anywhere in order to become an encrypted one. That ordering matters. Uploading an unprotected confidential file to a service so that it can hand you back a protected version means the unprotected version has already been somewhere you cannot audit.

Choose a passphrase, not a password

Encryption strength is bounded by the key, and the key comes from what you type. AES-256 protecting the passphrase Summer2026! is AES-256 protecting a guess that appears in every cracking dictionary.

Practical rules that survive contact with real use:

• Four or five unrelated words is stronger and far easier to relay over the phone than eight characters of punctuation soup.
• Never reuse the passphrase across recipients. One leak should not open every document you have ever sent.
• Avoid anything derivable from the document: the client name, the invoice number, the project code, the year.
• If the recipient will need it repeatedly, agree a scheme once rather than inventing a new one under time pressure each time.

Send the key separately, always

This is the discipline that decides whether the encryption was worth doing. If the password is in the email body, in the same thread, or in the filename, then anyone who obtained the message obtained both halves.

Workable separations, in rough order of preference:

1. A phone call or voice message.
2. A messaging app the recipient already uses, on a different account from their email.
3. A pre-agreed shared secret established before the document existed.
4. A separate email to a different address, as a last resort — weak, but still better than the same message.

Say the passphrase out loud rather than pasting it, and confirm the recipient can open the file before you delete your working copy.

Set the permission flags deliberately

Alongside the open password, you can set flags for printing, copying, editing, and form filling. Be honest with yourself about what these do: they are requests that compliant readers honour, not enforcement. Anyone who can open and read a document can retype it.

That does not make them pointless. They communicate intent, they prevent casual copy-and-paste into the wrong document, and they stop well-meaning colleagues from editing a file that should stay fixed. Just do not treat them as a substitute for the open password.

One flag deserves care: if you block content extraction outright, you may also block screen readers. Leave accessibility extraction permitted unless there is a specific reason not to.

Encryption does not fix what is inside the file

A password controls who can open the document. It does nothing about what the document reveals to the people who are supposed to open it.

Before encrypting, run two checks:

• Redaction. If parts of the content are not for this recipient, remove them properly with the redaction tool rather than covering them with a black rectangle. A drawn box travels inside the encrypted file and comes off with a single copy-and-paste once the recipient opens it.
• Metadata. Author names, editing timestamps, and originating file paths ride along untouched by encryption. Strip them first if the document is going outside your organisation.

After it arrives

Encryption is a transport measure, and transport ends. Once the recipient confirms receipt, the protected copy often becomes an obstacle: it will not index, will not preview, and will not open in three months when nobody remembers the passphrase. If the file is going into your own archive rather than someone else's inbox, decrypt your retained copy with the password removal tool and rely on the storage protections you actually control.

Encrypt for the journey. Do not encrypt for the shelf.