How to Share the Password for an Encrypted PDF or ZIP File Safely
An encrypted PDF, password-protected ZIP archive, or other encrypted document needs two things to stay useful: a file the recipient can open and a decryption password they receive safely. Treat those as separate steps. This guide explains how to send a file and password separately, what that can reduce, and where its limits remain.
A practical file-password workflow
Use this editorial framework, not an official security standard:
- 1Encrypt the file
- 2Verify the recipient
- 3Send the file
- 4Send the password separately
- 5Limit retention
Encryption and password delivery are different problems. File encryption protects contents while the encryption remains effective; the decryption password is a separate secret that deserves its own delivery decision.
First, choose a file option that actually encrypts
Not every PDF, ZIP archive, Office document, or file marked “password protected” offers equivalent protection. Use a current encryption method supported by both you and the recipient, and confirm that the chosen file format actually encrypts the file contents rather than merely restricting editing or opening behavior.
PDF passwords
PDF software may offer a document-open password and separate permissions that restrict editing or printing. Those settings serve different purposes. Confirm that the selected option protects opening the document and that the recipient can use the encrypted PDF.
ZIP and other archives
Archive encryption capabilities vary by format, tool, and configuration. Choose a modern encryption option that both parties support instead of relying on an unfamiliar default or legacy behavior.
Do not put the file and password together by default
If an encrypted attachment and its password sit in the same email, chat, or message thread, compromise of that location may expose both. Send the decryption password separately from the encrypted file after confirming the recipient. This can reduce risk from compromise of one message, account, or thread; it does not create perfect security, verify identity, stop endpoint malware, or prevent copies after decryption.
Verify the recipient before either delivery
Confirm the intended recipient, their address or account, that they expect the encrypted file, and that they can use the selected format. A separate password channel does not establish that the person receiving it is the intended recipient.
- Use previously known or independently obtained contact information for unexpected requests.
- Confirm the recipient expects this file and can open its encrypted format.
- Use the organization’s authenticated document portal when it already provides the appropriate workflow.
If the file goes by email
Modern email commonly uses TLS in transit where supported, but ordinary email generally is not end-to-end encrypted by default. Messages and attachments may remain in mailboxes and synchronized storage depending on configuration. Sending the password in the same email weakens the benefit of separating the secret. Read our guide to sending sensitive information by email for more context.
If the password goes by message
Standard SMS and MMS do not provide end-to-end encryption by default. Some messaging services do, but their message history and the recipient’s retention practices remain separate concerns. Choose an approach that fits the sensitivity of the file and the verified recipient’s workflow.
Where Paste & Purge fits
Paste & Purge can deliver the text decryption password separately from an encrypted document through an encrypted secret link with a configured expiration and view limit. Use it when the recipient has been verified, expects the workflow, and an organization’s own portal or native mechanism is not better.
Paste & Purge does not accept or transmit PDFs, ZIP files, images, documents, or arbitrary uploads. It does not encrypt the file itself, verify the recipient, make weak file encryption stronger, guarantee deletion, or control copies the recipient saves, forwards, prints, screenshots, or backs up after decryption.
For secrets with a configured view limit, server-side ciphertext is removed from active application storage once the final permitted retrieval occurs. Expired records are deleted through the application's expiration and cleanup mechanisms.
Use a difficult-to-guess, unique decryption password
Do not reuse an important account password as a document or archive password. A password manager can generate a strong random password for this temporary purpose. Avoid inventing arbitrary composition rules; use a password the encryption tool accepts and that is difficult to guess.
When this workflow is not the best choice
A lender, accountant, attorney, employer, or healthcare organization may provide an established authenticated upload or document portal. When that workflow is available and appropriate, use it instead of improvising encrypted attachments. For related situations, see our guides for sending tax documents to an accountant and sharing real-estate closing documents.
After the file is decrypted
An expiring password-delivery link does not revoke an already decrypted file. Copies the recipient saves, forwards, prints, screenshots, or backs up are outside your and Paste & Purge’s control.
If you send the encrypted file to the wrong person, revoke a file-sharing link where supported, determine whether they also received the password, and assess the underlying document. If the password was exposed, replace it, re-encrypt the file, and resend through a verified workflow when appropriate.