We never see your secret. Here's exactly how that works.
How a secret travels
The ciphertext and the decryption key take different paths. The key never reaches the server — not encrypted, not hashed, not at all.
What happens to it over time
Walk through it stage by stage
You type your secret into the create page. It never leaves your browser in this form.
Why not just use email or chat?
| Email / chat app | selfdestruct | |
|---|---|---|
| Where it lives afterward | Sits in inboxes, backups, and sync history — often on several devices | Nowhere — deleted from the server the moment it's read |
| Who could technically read it | The provider, anyone with inbox/backup access, forwarded threads | Only whoever holds the link — not us, not the server |
| Can it be opened more than once | Yes, indefinitely, by anyone with access | No — one successful reveal, then it's gone |
| Account required | Usually, for both sides | Never, for either side |
What we explicitly don't do
- No logs of secret contents, on any route
- No accounts, so no per-user records to build up
- No analytics or session-replay scripts on the create or reveal pages
- No backups of secret data — storage is genuinely ephemeral, not just deleted-looking
- No IP logging or device fingerprinting on reveal
- No read receipts by default, and never a way to tell if the duress passphrase was used
What's outside our control
Being honest about the edges matters as much as the guarantees above.
- A malicious or compromised browser extension on either device can still read page content
- Screenshots or copies made after a secret is revealed — we have no visibility into that
- Screen-recording software defeats this system the same way it defeats any other
- Clipboard managers or clipboard history on your device can retain a copied secret
- With JavaScript disabled, the page can't encrypt or decrypt anything, so it fails closed rather than falling back to a weaker method
The trade-off we accept on purpose
Because we don't log IPs or fingerprint visitors, we can't use those signals to throttle abuse the way many services do. We accept that deliberately, as the cost of genuine metadata minimisation — not as an oversight found later.
Frequently asked questions
What if someone intercepts the link?
Whoever opens the link first gets the one-and-only reveal — the secret is then destroyed. If that's not you, opening it yourself will show "no longer exists," which is itself a signal something's wrong. If you added a passphrase, an intercepted link alone isn't enough.
Can you read my secret?
No. Encryption and decryption both happen in your browser. The server only ever stores ciphertext, and the decryption key is never sent to it — it lives in the link itself, in a part of the URL browsers don't transmit to servers.
What happens after it's opened?
It's permanently deleted from the server in the same step as the reveal, not on a delay and not as a separate cleanup job. There's no way to view it a second time, including by us.
What if I lose the link before anyone opens it?
The secret is gone. There are no accounts and no recovery — that's by design, not a missing feature.
Do you use cookies or tracking scripts?
No. There are no accounts, no analytics or session-replay scripts, and no per-secret or per-visitor logging. We keep only coarse, anonymous aggregate counters (like a total-secrets-created number) with nothing tying a count back to a specific secret or person.
Is this really free?
Yes. Encryption strength, zero-knowledge architecture, and every safety feature are free for everyone. Paid tiers, if offered, only add convenience — branded links, longer expiries, API limits — never stronger privacy for a fee.
Warrant canary
As of 2026-08-27, selfdestruct has received zero government or third-party requests for user data, and made zero changes to add backdoors or weaken this product's encryption. This statement is dated and updated regularly. If it stops being updated, treat that absence itself as a signal.
Verify it yourself
The full source is public — the encryption, the atomic reveal-and-delete, the duress mechanism, all of it. Don't take the claims on this page on trust; read the code that makes them true.