We've all done it. Sent a password over Telegram. Emailed an API key.
Dropped credentials in Slack "just this once."
The problem? That message sits there. Forever. In plaintext.
One breach, one nosy admin, one leaked export — and it's out.
Why common tools fail
Most "secure sharing" tools encrypt data in transit (HTTPS),
but store it on the server in a way the server can read.
So you're trusting the server operator. Always.
That's fine — until it isn't. Like when 135K OpenClaw instances
leaked chat histories in plaintext last month.
The only safe model: client-side encryption
The key idea: encrypt before the data leaves your browser.
The server receives only an encrypted blob it can't decode.
The decryption key lives only in the URL fragment —
the part after #. Browsers never send the fragment to the server.
So even if the server is fully compromised, there's nothing useful to steal.
How I use this in practice
I built CreateSecureLink.com
exactly for this workflow:
- Paste your secret (password, token, private key)
- Get a one-time link — encryption happens in your browser
- Send the link to the recipient
- They open it once — it self-destructs immediately after
No account needed. No data stored server-side in readable form.
No "trust me" privacy policy.
When to use it
- Sending DB credentials to a new developer
- Sharing API keys with a client
- Passing a password to someone who doesn't use a password manager
- Any time you'd otherwise type a secret into a chat
The rule I follow: if it's sensitive and it needs to move,
it moves as a one-time encrypted link. Not a message.
Top comments (1)
Happy to answer any questions about the client-side encryption implementation. Also curious — how do you currently share credentials with teammates?