zero-knowledge · open source · self-destructing
The server can't read
your secrets.
Everything is encrypted and decrypted in your browser with AES-256-GCM. The server holds ciphertext for a little while and counts views. It has no key and no way to read anything — by design, not by policy.
Read the sourceHow it works
The flow
- 01A random 256-bit key and nonce are generated in your browser.
- 02Your
.envis encrypted locally. Only ciphertext goes to the server. - 03The key is placed in the link's
#fragment— browsers never send fragments to servers. - 04The recipient's browser reads the key from the fragment and decrypts locally.
- 05On open, the secret is burned: the ciphertext is deleted from the store.
Recipient-keyed drops
No key in the URL at all.
For channels you don't trust (WhatsApp, email, Slack), use a recipient-keyed drop. The sender never puts the key anywhere public.
- 01Bob generates a P-256 keypair in his browser. The private key never leaves his device.
- 02Bob shares his receive link — it contains only his public key, not a secret.
- 03Alice visits the link and encrypts with ECDH + HKDF into AES-256-GCM. The drop URL has no key fragment.
- 04Even if someone intercepts Alice's drop link, they get only ciphertext. Decryption requires Bob's private key.
Cryptographic primitives
What's under the hood.
| Primitive | Role |
|---|---|
| AES-256-GCM | Symmetric encryption for the secret payload |
| ECDH P-256 | Key agreement for recipient-keyed drops |
| HKDF-SHA-256 | Key derivation from ECDH shared secret |
| Web Crypto API | All crypto runs in the browser — no library code touches your plaintext |
What this covers
Protected threats.
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 to any server.
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.
Honest limits
Where the edges are.
We'd rather tell you the limits than overclaim. These gaps are inherent to every end-to-end web app.
A compromised device
If the sender's or receiver's machine is already owned, no web app can protect the plaintext once it's decrypted there.
Trusting the served JavaScript
You're trusting that the code we serve is the honest code. Mitigations: strict CSP, no third-party scripts on crypto pages, open repo you can audit or self-host.
A leaked link
Anyone with the full link can open the secret once. Use a recipient-keyed drop (via your receive address) if the channel isn't trustworthy.
Don't take our word for it.
The code is open. Audit it, file an issue, or run your own instance.