How to password-protect a PDF — and when AES-256 actually matters

A password-protected PDF isn't just a file with a prompt bolted on. The PDF spec defines actual encryption standards applied to the document's internal streams, plus a permissions layer controlling whether the file can be printed or copied even by someone who knows the password. Getting this right is a real cryptographic undertaking, not a checkbox.

Why this took a dedicated library

pdf-lib, the library this site uses for merging, splitting, and most page-level editing, deliberately doesn't implement encryption — it's a substantial, security-sensitive piece of work on its own. Protect PDF here uses a small, purpose-built library instead (@pdfsmaller/pdf-encrypt) that does nothing but PDF encryption, built on top of the Web Crypto API that's already built into your browser. Unlock works the same way in reverse, via its counterpart @pdfsmaller/pdf-decrypt.

What 'AES-256, in your browser' actually means

• The encryption itself runs through the Web Crypto API — the same browser-native cryptography primitive used for things like WebAuthn, not a hand-rolled implementation.
• Your file and your chosen password never leave your device — there's no server round-trip for either the file or the password, which matters since a password is exactly the kind of thing you don't want passing through a third party.
• The result is a standard encrypted PDF — it'll prompt for a password in Acrobat, Preview, or any other PDF reader, not just on this site.

The part encryption strength can't fix

AES-256 is a strong cipher, but it protects the file, not your choice of password. A PDF encrypted with a strong algorithm and the password "1234" is still trivially crackable — the algorithm was never the weak link. If the document actually matters, spend your effort on a long, unique password rather than worrying about which encryption standard is behind it; any modern implementation, including this one, uses one strong enough that it isn't the practical risk.