security
The server can’t read your secrets. Here’s how — and where the edges are.
Everything is encrypted and decrypted in your browser with AES-256-GCM. The server is a dumb vault: it holds ciphertext for a little while and counts views. It has no key and no way to read a secret — by design, not by policy.
Read the code →The flow
- 01 A random 256-bit key and nonce are generated in your browser.
- 02 Your
.envis encrypted locally. Only ciphertext is sent to us. - 03 The key is placed in the link’s
#fragment— which browsers never send to any server. - 04 The recipient’s browser reads the key from the fragment and decrypts locally.
- 05 On open, the secret is burned: the stored ciphertext is deleted.
What this protects
Database or server breach
Only ciphertext is stored. The key is never sent, so a full dump is noise.
Network sniffing
TLS in transit, and the key rides in the URL fragment — never transmitted.
Replay / re-reading a link
View-once burn plus a TTL the datastore enforces itself.
A rogue operator
Zero-knowledge means even we can’t read your secret. There’s nothing to hand over.
Where the edges are
We’d rather tell you the limits than overclaim. These gaps are inherent to every end-to-end web app — pretending otherwise would be the real security flaw.
A compromised device
If the sender’s or receiver’s machine is already owned, no web app can save the plaintext once it’s decrypted there.
Trusting the served JavaScript
You’re trusting that the code we serve is the honest code. That’s true of every end-to-end web app. Mitigations: strict CSP, no third-party scripts on crypto pages, and an open repo you can audit or self-host.
A leaked link
Anyone with the full link can open the secret once. Add a passphrase (shared over a separate channel) for links sent somewhere risky.
Don’t take our word for it
The code is open. Audit it, file an issue, or run your own copy.