Encrypt a PDF with AES-256, and check the result
Initializing in your browser…
Stamp a mark where the page really is, anchored or tiled
Draw, type or upload a signature and place it on the page a reader sees, at a width you can state in inches, on one page or every page. Transparent, so it does not hide the line you are signing on.
Join PDFs into one document, with a bookmark for each file
A payslip PDF must be encrypted before emailing it, and the recipient should be able to print it but not copy from it.
Input
payslip.pdf · AES-256 · preset "Read and print"
Output
V 5 R 6 /AESV3, /P -1340; refused with no password, opened with it, 4 pages and 19 characters read back
The permissions are written into the file as the /P entry by ISO 32000-1 table 22, so poppler reads them back as print:yes copy:no change:no addNotes:no, and the four presets give four different values. After writing, the tool re-opens its own output with a different implementation and reports what happened, so "this file is protected" is a measurement on the produced bytes rather than a claim. Everything happens in the browser and the password is never stored. Permissions are a request to a cooperating reader; the password is what keeps the document closed.
Encrypt a PDF so it cannot be opened without a password, and choose what a reader who has the password may then do with it. Three ciphers are offered and named: AES-256 (the current standard, and the default), AES-128, and RC4 128-bit for a reader too old to know either. Eight permissions are written into the file as the /P entry, and the page shows the exact value it is about to write. After it writes the file, the tool opens it again with a different reader and tells you what happened: whether a reader with no password was refused, whether the password worked, and how many pages and characters came back. Everything happens in your browser and nothing here stores the password.
Encrypt with a password you send by another route. Without it the file cannot be opened at all, whatever the permissions say.
Allow printing and screen reader access and nothing else, so a cooperating viewer does not offer copy or edit.
Set a separate owner password so you can change the permissions later without handing out the password readers use.
AES-256 is the current standard handler and is what a policy asking for strong PDF encryption usually means.
The "Read and print" preset writes /P -1340, and poppler reads it back as print:yes copy:no change:no addNotes:no. Four presets give four different /P values.
After writing, the tool re-opens the output with pdfjs: refused with no password, opened with the password, four pages and the text intact. That report is on the page.
A document with four bookmarks and a title comes back with all five strings readable after decryption, because a string is encrypted to bytes and stored as a hex string rather than as the text of its own hex.
A password on a PDF is the standard security handler of ISO 32000, and it has three parts that a tool can get wrong independently.
**The cipher.** Three are offered and each is named on the page rather than described in general terms. AES-256 is the default: it is the V5 revision 6 handler of ISO 32000-2 clause 7.6.4.3, whose key derivation is SHA-256, SHA-384 and SHA-512 with a hardened hash that repeats at least 64 rounds, and it opens in Acrobat X and every current reader. AES-128 is the V4 revision 4 handler with an /AESV2 crypt filter, which reaches back to Acrobat 7 but derives its key with MD5. RC4 128-bit is the old V2 revision 3 handler, offered only for a reader too old to know anything else; RC4 was REMOVED from PDF 2.0 and should not be chosen without a reason.
**The permission bits.** Eight capabilities are written into the /P entry by ISO 32000-1 table 22: printing, high resolution printing, copying, changing the content, commenting, filling in forms, rearranging pages and screen reader access. Each has its own bit, and /P is a SIGNED 32-bit integer with bits 7, 8 and 13 to 32 reserved and set, which is why "allow everything" is -4 rather than 0 or -1. The page shows the /P value it is about to write, and the four presets produce four genuinely different values.
**Two passwords, two roles.** The user password opens the document. The owner password grants full control and can change the permissions later without knowing the reading password. Leaving the owner password unset makes the two the same, which is the ordinary case.
And then the part that is usually only asserted: the tool reads its own output back. After writing the file it re-opens it with pdfjs, which is a different implementation that knows nothing about the code that produced it, and reports three things: that a reader with no password could not open it, that the password did open it, and how many pages and characters came back. The /Encrypt entries actually written are shown alongside. So "this file is protected" is a measurement on the produced bytes rather than a claim.
One thing is said plainly rather than implied: permissions are a request, not a lock. A reader that has the password holds the decryption key, so the bits are honoured by well behaved software and ignored by anything that chooses not to. The password is what keeps a document closed.
Whichever of the three you pick, and the page names it. AES-256 by default, which is the V5 revision 6 handler of ISO 32000-2 with a SHA-2 based key derivation. AES-128 is the V4 revision 4 handler with an /AESV2 crypt filter. RC4 128-bit is the old V2 revision 3 handler, offered only for compatibility with readers older than Acrobat 7.
They are written into the file as the /P entry, and the page shows you the exact value before you press anything. Whether a given reader honours them is up to that reader: a reader with the password holds the decryption key, so permissions are a request to well behaved software rather than a lock. The password is the part that keeps a document closed.
The tool opens the output again with a different implementation and reports what happened: whether a reader with no password was refused, whether yours worked, and how many pages and characters came back. That report is on the page after every run.
The document cannot be opened. Nothing here stores it, nothing is sent anywhere, and there is no recovery path. Put it in a password manager first.
The user password opens the document. The owner password grants full control, including changing the permissions, without being the password readers need. If you set only one, both roles use it.
No. This adds encryption; it does not remove it. An already encrypted file is recognised and refused rather than producing something that cannot be opened.
Yes. They are strings, and a string is encrypted to bytes and stored as a hex string object, which is what the specification means. Storing the TEXT of the hex instead is a common mistake that destroys every title in the document.
PDF parsing and editing happen in your browser. Documents, and everything inside them, are never uploaded or stored remotely.