Encrypting vs. Password-Protecting: What Protect and Unlock Actually Do
Password-protecting a PDF is encryption with an open password. Protect adds it; Unlock removes it when you know it. Neither recovers a forgotten password.
People say "password-protect a PDF" and "encrypt a PDF" as if they were different products. In the PDF format they are the same family of mechanism: the file carries an /Encrypt dictionary, and viewers need a password (or equivalent credentials) before they hand you page content in the clear.
What "password protect" actually means
A protected PDF is not merely a UI lock in one app. Standards-compliant readers refuse to open the document until the correct open password is supplied. That is encryption of the file's contents, keyed so that the password is required to decrypt.
Protect PDF (POST /api/v1/security/add-password) takes a password you choose and returns an encrypted file that prompts for that password on open. The portal form asks for one password field. The server encrypts via qpdf (--encrypt), using that value as the user (open) password; if no separate owner password is supplied to the API, the same string is used for the owner role. Default key length is 256 bits. The tool does not store your password after processing finishes. If you lose it, the resulting file stays locked.
User password vs owner password
PDF encryption historically distinguishes two roles:
- User (open) password: required to open and view the document at all.
- Owner (permissions) password: often used to set print/modify restrictions while still letting someone open the file with the user password (or with empty open password, depending on how the file was authored).
Those are format concepts, not marketing labels. Many everyday "lock this PDF" workflows only set an open password. Restricting print or edit without blocking open is a permissions story that uses the owner role; it is easy to confuse with "the file won't open."
On PDF123, the Protect form asks for one password and treats it as the open password required to view the file. Unlock needs that same known password to decrypt. Advanced API callers can pass ownerPassword, keyLength, canPrint, and canModify on add-password; the browser form does not expose those knobs.
What Unlock does (and does not)
Remove Password (POST /api/v1/security/remove-password) strips existing password encryption when you supply the correct current password. The pages, fonts, and layout stay the same; only the encryption requirement goes away.
It does not recover, guess, or crack a forgotten password. If you do not already know the password, Unlock will not invent one. Repair does not remove encryption eitherâGet Info reporting Encrypted: true means unlock first, then edit.
When to use which
| Goal | Tool |
|---|---|
| Require a password to open before sending or sharing | Protect |
| You already know the password and want a freely openable copy | Unlock |
| You forgot the password | Neither tool can help; keep passwords outside the PDF |
| File will not open for structural reasons (not encryption) | Repair / Get Info, not Unlock |
Both Protect and Unlock run server-side with no account on the catalog path. Encrypting does not shrink the file; Compress is a separate stream-recompression job and still needs an unlocked (or never-encrypted) PDF. OCR, table export, and most edit ops likewise need cleartext access firstâUnlock with a known password, then run the other tool.
Store passwords outside the PDF (password manager, secrets store). Putting the open password in the same email as the attachment defeats the protection. For the same jobs over HTTP, see Developers.