I wrote this as a note to the person who keeps asking me to “just put a password on the signed PDF” five minutes before it goes to a client. The button exists. The thing it produces is not the file you think you are locking.
What the button does to the bytes
Lock PDF opens the document in PDF.js, draws every page at scale 1.5, encodes that bitmap as JPEG at quality 0.92, and builds a new PDF in jsPDF. The constructor sets encryption.userPassword and ownerPassword to the same string you typed, with permissions listed as print, modify, copy, and annot-forms. If the browser cannot create that encrypted document, the script tells you to try Chrome or Edge. The password must be at least 4 characters and the two fields must match. That is the entire policy engine. There is no strength meter.
So the recipient who knows the password opens a picture of your pages. They do not open your original content streams. Search, copy-as-text, and live form fields from the source are gone, replaced by paint. The password stops a casual opener. It does not stop a screenshot, and it does not preserve the digital original inside a vault. You still have the digital original only if you did not throw it away.
| Original PDF | Locked download | |
|---|---|---|
| Page content | Text, vectors, images as authored | JPEG per page, scale 1.5, quality 0.92 |
| Open without password | Yes, if it was unlocked | No |
| Highlight a sentence | Yes, when it was real text | No |
| Password recovery | — | None. The tool cannot fetch it back |
| Minimum password | — | 4 characters. Please do not use 4 characters |
A password that is not a joke
“1234” satisfies the length check. It does not satisfy anyone who receives contracts for a living. I use a manager-generated string, different per file, and I send it on a different channel than the file. Same email as the attachment is a ritual, not a control. SMS to a number you already use for that client is the minimum I will bother with. A shared Slack channel titled “passwords” is how the lock becomes decoration.
I test both directions before I send. Open the download, type the password, see page 1. Then open it again and cancel the prompt. If it opens on cancel, you did not lock it. If Chrome says the encryption constructor failed, you do not have a locked file either. You have an error string. Read it.
Owner and user password are the same value in this implementation. Do not plan a workflow where staff can print but not open, or open but not print, as separate secrets. The permission array is set, and the two passwords are not different. Assume the secret gates opening. Test anything finer in a desktop reader with a sample before you promise it to a lawyer.
When to lock, relative to signing and compressing
Sign the visual signature on the real PDF first, using Sign PDF, while the page is still a page and not a JPEG. Then lock, once, as the distribution copy. If you compress first, you have already rasterized. Locking rasterizes again. Two JPEG passes on a signature is how a pen stroke turns into crumbs. One pass, at lock time, on a file that still looks right at 150% zoom.
If the document must stay searchable for the recipient, do not use this lock. Send it through a channel that is access-controlled, or use an encryption tool that wraps the original PDF without repainting. I will not describe a pile of third-party products here. I will say this button is the wrong button for “password, but please keep the text layer.” It cannot. The repaint is the mechanism, not a side effect I can toggle off.
Store the unlocked master. Lock a copy. If you lock the only copy and forget the password, that document is done.
What this does not defend against
Anyone who can open the file can photograph the screen. A 4-character password can be guessed. A password written in the email can be forwarded with the file. Malware on the recipient’s machine does not care that jsPDF set a user password. This is a courtesy latch for honest recipients and a speed bump for casual snooping. It is not a security program, and I do not write it into a threat model as if it were full-disk encryption.
File size often drops or shifts because JPEG at 0.92 replaced whatever the images were before, and text became images too. A text-only 200 KB letter can come back larger. A photo-heavy scan can come back smaller. Judge the locked file with your eyes before you congratulate yourself on the megabytes. If the fee table is unreadable, raise nothing — there is no quality slider on the lock page. The numbers are fixed. If they are too soft, this distribution method is too soft for that page.
I keep the password in the manager entry next to the filename and the date, not in a spreadsheet called passwords-2026.xlsx sitting in the same Drive folder as the PDF. The spreadsheet gets shared when someone shares the folder. I have watched that happen. The manager entry does not travel with the zip file.
For the internal archive, I store the unlocked master and I do not lock it “so it’s consistent.” Consistency belongs on the copy that leaves. The archive should open in a hurry at 11 p.m. without a scavenger hunt. Label the locked file agreement-client-locked.pdf so nobody merges it into a packet and then wonders why half the pages will not select. Merge will also refuse many encrypted inputs until they are unlocked, which is another reason the locked file is a delivery artifact, not a working file.
A password I almost put in the filename
Someone had been naming files contract-pw-acme2024.pdf. The lock was real. The filename was the key, and the filename was in every sync client, every recent-files list, and the email subject when a mailer used the attachment name. I renamed the file to something dull and put the secret in the manager. Then I rotated the password, because the old one had already traveled with the name. Rotating meant a new locked copy from the master, not a rename. The old locked file was retired. People keep opening the old attachment from a thread. I sent a one-line correction and I did not attach the new file to the same thread as a pile of previous copies. New thread, new file, secret on the other channel.
Shared inboxes are where locks go to die. The password gets pinned in the channel topic “for convenience.” I would rather the file be unlocked on an access-controlled drive than locked with the key in the topic. The lock is for a path you do not control: a client’s mailbox, a portal that is not yours. On a path you control, use the path’s permissions and keep the PDF as real text. You will want to search it next month, and the JPEG stack will not let you.
I also check the locked file on a phone, not only on the desktop that created it. Mobile viewers are fussier about jsPDF’s encryption, and a file that opens in Chrome can throw a password loop in another viewer even when the password is right. If the recipient lives on a phone, that is the test that counts. Send yourself the file, open it on the phone, type the password once. Then send it to them.