Share a Password with a Secure Link
Passwords sent by email or chat live forever in searchable history, backups, and forwarded threads. A secure secret link fixes the handoff: your secret is encrypted in your browser, the server stores only ciphertext with expiry rules, and the decryption key rides in the part of the URL that browsers never send to servers. When the link expires, the ciphertext is deleted.
The actual tool runs in our ad-free secure workspace — nothing on this page processes your file.
Open Share a One-Time Secret →What this tool does
- Encrypts your secret (a password, API credential, or short note up to 64 KB) in your browser before anything is transmitted.
- Generates a share link whose decryption key lives in the URL fragment (after the #) — the one part of a URL browsers never transmit to servers.
- Lets you set expiry rules: a time limit, a one-view limit, or both.
- Deletes the stored ciphertext when the secret expires or is viewed, whichever rule fires first.
- Optionally adds a passphrase requirement on top of the link for higher-stakes handoffs.
Your privacy on this tool
Stays on your device
- The secret is encrypted with a randomly generated key inside your browser before upload.
- The decryption key is placed in the URL fragment (#...), which your browser never sends to any server — ours included.
- Decryption happens in the recipient's browser after the ciphertext is fetched.
Reaches our server
- The server stores the encrypted ciphertext of your secret and its expiry/view rules (for example: one view, or 24 hours) — nothing else.
- The server never receives the decryption key, so it cannot read the secret it is holding.
- When a secret is viewed or expires, its ciphertext is deleted.
How to use it
- Open the tool at /app/secure-secret.
- Type or paste the secret — a password, connection string, or short note.
- Choose expiry rules: one-time view, a time window, or both.
- Create the link; encryption happens locally before the ciphertext is stored.
- Send the link to the recipient — and if the stakes are high, send an added passphrase through a second channel.
- Confirm with the recipient that they retrieved it; a one-time link that was already consumed is your tamper signal.
Common uses
- Handing a new employee their first-login credentials without leaving them in email history.
- Sending a client their database or CMS password at project handover.
- Sharing the Wi-Fi or door-code details with a contractor for one week only.
- Passing an API key to a freelancer without pasting it into a chat that syncs to their phone, laptop, and backups.
- Giving a family member the password to an encrypted file you emailed separately.
Supported formats
- Text up to 64 KB — passwords, API keys, connection strings, short notes
Both creating and viewing links work in all modern browsers on desktop and mobile.
Limitations & security notes
Limitations
- Corporate email scanners and chat link-preview bots sometimes open links automatically — which consumes a one-time secret before the human sees it. Time-based expiry or an extra passphrase mitigates this.
- Once the recipient views the secret, they can copy it, screenshot it, or write it down — expiry controls availability, not what the recipient does with the knowledge.
- Secrets are capped at 64 KB of text; this is for credentials and notes, not files.
- Anyone who obtains the full link before expiry can read the secret — the link is the key, so treat it like one.
- SecretPNG is in beta and has not been independently audited.
Security notes
- The design goal is a small attack window: even if our server were seized or breached, it holds ciphertext and expiry rules, not keys or plaintext.
- URL fragments are never sent in HTTP requests — that is a browser standard, and it is what keeps the key out of our hands and our logs.
- For sensitive handoffs, enable the extra passphrase and deliver it by a different channel than the link.
- Prefer one-time view for credentials: if the legitimate recipient finds the link already consumed, you know someone or something else opened it — rotate the credential.
- Never send the link and any added passphrase in the same message thread.
Frequently asked questions
- If the ciphertext is on your server, can't you read my secret?
- No — the decryption key never reaches us. It is generated in your browser and embedded in the URL fragment (the part after #), which browsers do not include in requests to servers. We store ciphertext we cannot decrypt, plus the expiry rules. This design is verifiable in your browser's developer tools.
- What happens when the link expires?
- The stored ciphertext is deleted, and the link stops working permanently. Whether expiry comes from a view (one-time links) or from time, there is no grace period or recovery — send a new secret if the recipient missed it.
- Is a secure link actually better than just texting the password?
- Yes, in one specific way: persistence. A texted password sits in message history, backups, and synced devices indefinitely. A secret link removes the secret from storage after view or expiry, so the long tail of exposure disappears. It does not protect against an untrustworthy recipient — nothing does.
- My recipient says the one-time link was already used. What happened?
- Most likely an automated system opened it first: corporate email security scanners and chat apps' link-preview bots fetch URLs, and that fetch can consume a one-time view. Resend with a time-based expiry plus an added passphrase, or use a channel that does not auto-preview links. Treat the consumed secret as exposed and rotate it if it was a live credential.
- Can I send a file this way?
- Not through the secret link — it is limited to 64 KB of text by design. For files, encrypt them with the file-encryption tool, send the .svault by any channel you like, and share its password via a secure secret link. The two tools are built to combine exactly this way.
Related tools
Last reviewed: 2026-07-14Open Share a One-Time Secret
SecretPNG is in beta and has not been independently audited. Security status.