How to password-protect a client pdf deliverable
- Step 1Finalise the client deliverable PDF — Complete the report or opinion and export the final PDF. Encryption is the last step before delivery.
- Step 2Scrub internal metadata if needed — Deliverables exported from internal templates often carry your firm's author name, file path, or software in the metadata. Run the metadata scrubber first if you don't want that travelling with the file.
- Step 3Open the Password Protect tool and drop the deliverable — Load it into the PDF Password Protect tool. One PDF at a time; free tier up to 2 MB / 50 pages, Pro up to 50 MB / 500 pages.
- Step 4Set a unique per-client password — Generate a random 16-character password in your password manager and paste it into the single
Set passwordfield. A distinct password per engagement keeps a leak contained to one client. - Step 5Encrypt, download, and log the password — Download the encrypted deliverable and store the password in your password manager against the client engagement, so the team can retrieve it if the client asks again.
- Step 6Deliver the file and password through separate channels — Send the encrypted PDF by email or portal, and the password by a different channel (SMS, a call, a separate secure message). Mention the client must download the file — portals and email previews may not open encrypted PDFs inline.
Per-client delivery log (recommended practice)
What to record in your password manager per engagement — a clean handling trail for client-confidentiality obligations.
| Field to log | Example | Why |
|---|---|---|
| Engagement / client | Acme Ltd — FY26 audit | Ties the password to the deliverable |
| Password | 16-char random from manager | Retrievable if the client loses it |
| Delivery channel for file | Email / client portal | Audit trail of how it was sent |
| Channel for password | SMS to engagement lead | Proof the key went out-of-band |
| Date delivered | 2026-06-06 | Confidentiality timeline |
Encryption vs. what clients sometimes ask for
Set expectations: an open password is transport security, not DRM.
| Client requirement | Does this tool do it? | What actually delivers it |
|---|---|---|
| Only the client can open the file | Yes — AES-256 open password | This tool |
| Client can't print or copy the report | No | pdf-permission-setter |
| Remove your firm's internal metadata | No (encrypt only) | pdf-metadata-scrubber |
| Track who opened it / revoke access | No | A DRM / document-tracking platform |
| Tamper-evidence / signer identity | No | pdf-signature-verify |
Cookbook
Professional-services delivery scenarios and the precise tool behaviour for each.
Delivering an audit report to one client
Encrypt with a manager-generated per-client password, log it against the engagement, deliver, and text the key. A misaddressed email leaks nothing usable.
Input: Acme-FY26-audit-report.pdf (22 pages, 1.3 MB) Manager generates: "7Kp$2mQrLz9vXn4w" (16 random chars) Field: Set password = "7Kp$2mQrLz9vXn4w" Log in vault: Acme Ltd / FY26 audit / sent via portal / 2026-06-06 Deliver encrypted PDF via client portal; SMS the password.
Scrub firm metadata, then encrypt a legal opinion
Internal templates leak the partner's name and the firm's file server path in the producer/creator fields. Strip them, then encrypt for the client.
Step 1 — pdf-metadata-scrubber: Author "j.smith" -> (cleared) Producer "WordPerfect/InternalTpl" -> (cleared) Step 2 — pdf-password-protect: Set password = vault-generated per-client key The client receives a clean, encrypted opinion.
Re-sending a lost password from the vault
A client emails: "I can't open the report." Because you logged the password against the engagement, retrieval is instant — no re-encrypting needed.
Client: "What's the password for the FY26 report?" Look up vault entry: Acme Ltd / FY26 audit -> "7Kp$2mQrLz9vXn4w" Re-send via the secure channel (SMS). The deliverable itself is unchanged; only the key is re-shared.
Client asks for a no-print version
Some clients want the report viewable but not printable. This tool can't do that — it allows printing once opened. Use the permission setter for that requirement.
Requirement: "View only, no printing." pdf-password-protect alone: print is allowed after open. Use pdf-permission-setter: Owner password = set Block printing = on -> report opens but Print is disabled.
Empty password is refused — no accidental plaintext delivery
Click run with the field blank and the tool stops you, rather than delivering an unprotected report that you think is encrypted.
Field: Set password = "" Result: Error — "Enter a password." No file produced. No risk of shipping a client deliverable in the clear by accident.
Edge cases and what actually happens
Client expected printing/copying to be blocked
By designAn open password lets the client open the file but does not restrict printing, copying, or editing afterwards (--print=full --extract=y --modify=all). If the engagement requires view-only delivery, use the permission setter with Block printing / Block copying enabled.
Engagement needs a separate owner password
ExpectedThis tool has one password field, so the open and owner passwords match. If you need to give the client an open password while retaining a different owner password for your firm, use the permission setter, which exposes a dedicated owner field.
Deliverable exceeds the tier size limit
BlockedLarge reports with charts or scanned exhibits can exceed the 2 MB free limit. Compress with the lossy compressor to fit, or use Pro (50 MB / 500 pages). Over-limit files are blocked before processing.
The deliverable is already encrypted
ErrorIf the source PDF already carries a password, qpdf can't read it to re-encrypt and the tool errors (exit code 2). Decrypt with the remove-password tool first, then apply the new per-client password.
Client wants to know who opened the report and when
Out of scopeAn open password is access control at the file level — it can't track opens, log readers, or revoke access remotely. That requires a DRM or document-tracking platform. This tool stops anyone without the password from opening the file; that's the boundary.
Client portal can't preview the encrypted file
ExpectedMany client portals and email previews won't render an encrypted PDF inline. The client must download it and open it in a PDF reader, which prompts for the password. Note this in your delivery message to avoid a support exchange.
Client loses the password
Recoverable from your vaultBecause you logged the per-client password against the engagement, you can re-send it instantly. If you didn't log it and you've lost it too, there's no recovery — AES-256 with a strong password can't be brute-forced. Keep the source deliverable until access is confirmed.
qpdf warning on a deliverable assembled from many sources
PreservedA report merged from multiple exhibits may hit qpdf's warning path (exit code 3), but the encrypted output is valid and returned. Open it once to confirm the prompt before delivering.
Frequently asked questions
How do I choose a good per-client password?
Generate a random 16-character password in your password manager for each engagement and paste it into the single field. Random per-client passwords mean a leak is contained to one client, and your vault gives the team a retrievable record.
Does the password stop the client printing or copying the report?
No. This tool sets an open password and allows printing, copying, and editing once the file is open. If the engagement requires a view-only or no-print deliverable, use the Permission Setter, which adds an owner password and lets you block those actions.
Can I set a different owner password to keep control?
Not in this tool — it has one field, so the open and owner passwords are identical. The Permission Setter exposes a separate owner password if you need to let the client open the file while your firm retains permission control.
What if the client loses the password?
Look it up in your password manager against the engagement and re-send it through the secure channel. That's why logging the password per client is recommended — retrieval is instant and you don't need to re-encrypt the file.
Will password protection satisfy a client's contractual security requirement?
AES-256 encryption satisfies typical transport- and at-rest-confidentiality requirements and demonstrates professional handling. For requirements involving access tracking, revocation, or rights management, you'll need a dedicated DRM platform — password protection alone doesn't provide those.
What encryption does it apply?
Real AES-256, run by a qpdf WebAssembly build in your browser. The unencrypted deliverable and the password never reach a server or any third-party processor, which keeps client data off external processing paths entirely.
Is the deliverable ever uploaded anywhere?
No. All processing is local in your browser. Only the encrypted result is downloaded; the plaintext deliverable and password stay on your device. This is often itself a selling point to security-conscious clients.
Can I remove my firm's internal metadata before sending?
Yes — run the deliverable through the Metadata Scrubber first to clear author, producer, creator, and dates, then encrypt. The password protects the content; the scrubber removes the internal trail that would otherwise travel with it.
The client says the file won't open in their portal — why?
Portals and email previews generally can't render encrypted PDFs inline. The client needs to download the file and open it in a PDF reader, which will prompt for the password. It's standard behaviour for encrypted files, not a fault.
Can I encrypt several client deliverables at once?
On Pro, batch mode allows up to 5 files; on free it's one at a time. Since each client typically gets a distinct password, you'd usually encrypt deliverables one per client regardless.
Can the client remove the password for their own archive?
Yes — with the Remove Password tool and the password you provided, they can produce an unlocked copy for their records. qpdf decrypts given either the user or owner password, which are the same value here.
What happens if I forget to set a password?
You can't ship an unprotected file by accident — a blank password is rejected with "Enter a password." and no file is produced. You'll always either deliver an encrypted file or get a clear error.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.