Secure Send
Stop pasting passwords into Slack. Stop emailing API keys in plain text. Secure Send lets you share sensitive information through encrypted, self-destructing links — with a decryption key that never touches our servers.
Think of it as a sealed envelope that burns itself after being read.
Why you need Secure Send
Every team has moments where sensitive data needs to change hands — a database password for a new hire, a recovery code for a colleague, an API key for a contractor. The usual channels (email, Slack, text messages) store that data forever, often in plain text, across servers you don't control.
Secure Send eliminates that risk. Your secret is encrypted before it leaves your browser, wrapped in a link that automatically expires, and the decryption key never reaches Passwall's servers. Once the link is used or expires, the encrypted data is purged.
Perfect for
- Passwords & credentials — Share login details with colleagues without them lingering in chat history.
- API keys & tokens — Send infrastructure secrets to contractors with one-time access.
- Recovery codes — Pass 2FA backup codes through a secure channel instead of screenshots.
- Personal information — Share tax IDs, account numbers, or other sensitive data with trusted recipients.
- Onboarding — Give new team members their initial credentials through a link that destroys itself after first use.
How it works
Secure Send uses a cryptographic pattern called key-in-fragment that ensures true zero-knowledge sharing:
- Encrypt locally — Your browser generates a random 512-bit SendKey and encrypts your text with AES-256-CBC + HMAC-SHA256 before anything leaves your device.
- Upload ciphertext — Only the encrypted blob is sent to the Passwall server. The server never receives or stores the SendKey.
- Generate the link — The SendKey is placed in the URL hash fragment (the part after
#). Hash fragments are never sent to the server by web browsers — this is an HTTP standard, not a Passwall promise. - Share the link — You send the full URL to your recipient through any channel (Slack, email, text).
- Decrypt on arrival — The recipient opens the link, their browser extracts the SendKey from the hash fragment, fetches the encrypted data from the server, and decrypts everything locally.
The result
The server stores only meaningless encrypted bytes. The decryption key travels exclusively through the URL. Even if Passwall's database were compromised, your shared secret would be unreadable.
Creating a send
Creating a Secure Send takes about 30 seconds:
- Navigate to Send in the sidebar of the web vault.
- Click New Send to open the creation dialog.
- Enter a name (visible to the recipient as the subject line) and paste your secret text.
- Configure access controls (all optional):
- Expiration — How many days until the link stops working (default: 7 days, max: 30 days).
- Max views — Limit the number of times the link can be opened. Set to 1 for a one-time secret.
- Password — Require an additional password to view the content, adding a second layer of protection.
- Hide email — Choose whether the recipient sees your email address.
- Click Create & Get Link. Your browser encrypts the text, sends the ciphertext to the server, and generates the shareable link with the key in the fragment.
- Copy the link and share it with your recipient.
Important
The link is shown only once. Passwall does not store the decryption key, so if you lose the link, there is no way to recover it. Copy it immediately.
Opening a send link
When someone sends you a Secure Send link, here's what happens:
- Click the link. You'll be asked to sign in to Passwall if you aren't already (recipients must have a Passwall account).
- If the send is password-protected, you'll see a password prompt. Enter the password the sender shared with you through a separate channel.
- Your browser extracts the decryption key from the URL, fetches the encrypted data from the server, and decrypts everything locally.
- The decrypted content is displayed in a read-only viewer with a Copy button for easy use.
A subtle notice at the bottom confirms: "This content was decrypted locally in your browser. The server never had access to the decryption key."
What if the link doesn't work?
- The send may have expired — check with the sender.
- The view limit may have been reached — ask the sender to create a new send.
- The URL may be truncated — make sure you have the complete link including the
#portion. - The sender may have deleted the send.
Zero-knowledge architecture
Secure Send is built on the same zero-knowledge principles that underpin all of Passwall:
- Client-side encryption — Text is encrypted in your browser with AES-256-CBC + HMAC-SHA256 using a randomly generated 512-bit SendKey. Encryption and decryption happen exclusively on the client.
- Key-in-fragment pattern — The SendKey is embedded in the URL hash fragment (
#). Per the HTTP specification (RFC 3986), hash fragments are never transmitted to servers in HTTP requests. This is enforced by every browser, not by Passwall. - Password protection — When a send is password-protected, the server withholds the encrypted payload until the correct password is verified. The encrypted data is only delivered after successful authentication, preventing brute-force content extraction.
- Server blindness — The server stores only the encrypted ciphertext and metadata (name, access count, expiration). It never receives, processes, or logs the SendKey.
- Automatic purge — A background cleanup job permanently deletes expired sends every 6 hours. There is no recovery after deletion.
- Organization policy support — Admins can enforce a "Remove Send" policy that prevents non-admin members from creating sends, giving organizations control over data exfiltration risk.
What an attacker sees if they compromise the server
A table of AES-256 encrypted blobs with no decryption keys. Metadata like names and access counts are visible, but the actual secret content is mathematically unrecoverable without the key that only existed in the URL.
Access controls
Every send comes with granular controls that let you decide exactly how, when, and how often the secret can be accessed:
| Control | Default | Description |
|---|---|---|
| Expiration | 7 days | The link stops working after this date. Range: 1–30 days. |
| Deletion date | Expiry + 1 day | The encrypted data is permanently purged from the server. |
| Max views | Unlimited | Limit how many times the link can be opened. Set to 1 for a true one-time secret. |
| Password | None | Require an additional password before the encrypted data is delivered. Share the password through a different channel than the link. |
| Hide email | Off | When enabled, the recipient does not see your email address. |
| Disable | — | Immediately deactivate a send without deleting it. The link will return "not found" until re-enabled. |
Pro tip
For maximum security, combine max views = 1 with a password. Send the link via one channel (e.g., Slack) and the password via another (e.g., SMS). This way, compromising a single channel isn't enough to access the secret.
Managing your sends
The Send page in the web vault gives you a dashboard of all your active sends:
- View count — See how many times each send has been accessed (and whether it's hit the limit).
- Status badges — At a glance, see if a send is active, expired, disabled, or at max views.
- Delete — Permanently deactivate and soft-delete a send. The encrypted data is purged on the next cleanup cycle.
Sends that pass their deletion date are automatically and permanently removed by a background job that runs every 6 hours. No manual cleanup is needed.
Frequently asked questions
Does the recipient need a Passwall account?
Yes. Recipients must sign in to Passwall to open a send link. This prevents anonymous access and ensures only authenticated users can reach the encrypted content. Free accounts work — no paid plan is required.
Can I send files, or only text?
Currently, Secure Send supports text only. File attachments are on the roadmap for a future release.
What happens if the URL gets truncated (e.g., in an email)?
The decryption key is in the hash fragment at the end of the URL. If the URL is truncated, the key is lost and the content cannot be decrypted. A "Decryption Failed" message will be shown. Ask the sender for the full link, or use a channel that preserves long URLs (like a direct message).
Can Passwall staff read my sends?
No. The decryption key is embedded in the URL hash fragment and is never sent to or stored on our servers. We physically cannot decrypt the content. This isn't a policy — it's a mathematical guarantee of the zero-knowledge architecture.
What if I lose the link after creating a send?
The link (including the decryption key) is shown only once during creation. Passwall does not store the key. If you lose it, there is no way to recover the decryption key. Delete the send and create a new one.
How is the password protection different from the encryption?
They are two independent layers. The encryption (AES-256) protects the content mathematically — even the server cannot read it. The password adds an access-control gate: the server won't release the encrypted payload until the correct password is provided. Combined, they provide defense in depth.
Can my organization admin disable Secure Send?
Yes. Organization admins can enable the "Remove Send" policy, which prevents non-admin members from creating new sends. This gives security teams control over data exfiltration vectors while still allowing admins to use the feature when needed.
Is there a size limit for the text?
Secure Send is designed for short-to-medium text content like passwords, keys, and notes. The practical limit is around 10,000 characters. For larger payloads, consider using the vault's direct sharing features.
Stop sharing secrets in plain text
Secure Send is available on all Passwall plans. Create your first encrypted, self-destructing link in under 30 seconds.