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.
Two examples. Say you're walking a relative through their online banking on a Zoom call and need to hand them a PIN — instead of reading it aloud on a recorded call or pasting it into Zoom's chat, where it sits in the meeting history afterward, you paste it here and send the link; they open it once, after the call ends. Or say you're a sysadmin handing a contractor a database password — you paste it in and drop the link in a Teams or Slack channel instead of the password itself, so it's gone the moment they've read it, with nothing permanent left in that channel's history for the next person with access to stumble on.
Either way, the mechanics are identical: your browser encrypts the secret and sends only the resulting ciphertext to us — that's all we ever store. The key stays in the link itself, after the #, a part of the URL browsers never transmit anywhere. When the recipient opens the link, it's their browser, not ours, that reconstructs the key and decrypts the secret. At no point does a copy of the plaintext or the key pass through anything we run.
What happens to it over time
Using a passphrase
By default, anyone with the link can open your secret — that's normal, and fine for most things. Adding a passphrase changes that: the link alone stops at a locked state. The recipient also needs the passphrase, which you send through a completely different channel — a phone call, a different app, in person. Never alongside the link itself, or you've just recreated the same single point of failure a passphrase is meant to avoid.
This matters whenever the link itself might end up somewhere you don't control — forwarded by accident, sitting in a browser history, logged by a proxy along the way. The passphrase is a second, independent barrier that never sits next to the link anywhere.
If you're worried about being pressured into handing a passphrase over, you can also set a duress passphrase — a second one that opens a decoy message instead of the real secret, and permanently destroys the real one at the same moment. Afterward, there's no way for anyone — including you — to tell which passphrase was actually used.
For example: you set your real passphrase to unlock the actual secret, and a duress passphrase that instead unlocks something harmless-looking — a grocery list, a note that says "nothing here." Both passphrases go into the exact same single field on the reveal page; nothing about the page, the request, or the response differs based on which one gets typed. If you're ever forced to open it in front of someone, entering the duress passphrase shows them the decoy and permanently destroys the real secret in the same instant — there is no third state like "duress was used" stored anywhere, for anyone to find later, including you.
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 — for example, a link sitting unread in a hacked email account is useless without it.
Can you read my secret?
No. Encryption and decryption both happen in your browser. All we ever receive is scrambled bytes — the decryption key never reaches us, since it lives in the link itself, in a part of the URL browsers don't transmit to servers.
What encryption does this actually use?
AES-256-GCM, generated and run through your browser's built-in Web Crypto API — not a library we wrote ourselves. Every secret gets its own one-time key; nothing is ever reused across secrets. The full implementation is public — see "Verify it yourself" below rather than take our word for it.
Is this protected against quantum computers?
The connection between your browser and our server already is — it uses post-quantum hybrid key exchange (ML-KEM), confirmed with a real test against the live site, not just a setting we assume is on. That protects the scrambled data in transit from a "harvest now, decrypt later" attack. It doesn't extend to however you send the link itself (text, email, chat) — that's a channel we have no part in and can't control, so its own security depends on whatever app you used to send it.
What happens after it's opened?
It's permanently deleted from the server in the same atomic 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 — a second visit to the same link gets "no longer exists," not a cached copy.
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. Treat the link itself as the only copy that exists anywhere, because it is.
How big a secret can I send, and can I attach a file?
Up to 100,000 characters of text — enough for a full config file or a long block of credentials, not just a single password. There's no file, image, or attachment support, and there won't be: keeping this to text only is what makes the zero-knowledge guarantee simple enough to actually verify, rather than a promise about a much larger, harder-to-audit surface.
How long can a link stay active?
You choose at creation: 5 minutes, 1 hour, 1 day, or 7 days. Whichever comes first — the expiry or someone opening it — ends the secret's life. There's no way to extend an expiry after the fact, and no way to shorten it either once it's set.
Why does the reveal page need an extra click instead of just showing the secret?
Requiring an explicit "Reveal secret" click, rather than decrypting automatically the instant the page loads, stops a link-preview bot (Slack, Teams, and similar apps often fetch a link automatically to generate a preview) from silently burning a secret before the real recipient ever sees it.
Why would I ever use the duress passphrase?
For anyone who might be forced to open a secret in front of someone else — handing over a phone at a border crossing, or under direct pressure from someone standing over your shoulder. Typing the duress passphrase instead of the real one shows a harmless decoy and destroys the real secret in the same instant, and nothing about the page or the response gives away that a duress passphrase was used, even to you afterward.
Is there a limit on how many secrets I can create?
Yes — up to 50 per hour, per browser. It's an anti-abuse limit, not IP-based (see the cookies question below), so it's easy to reset by switching browsers, and it exists purely to slow down automated abuse, not to cap normal use. It's shared with the batch-send page, so a large batch (or a couple close together) can use up a real chunk of it — if you hit the limit partway through a batch, the links already created are still live; wait a bit before creating more.
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-28, 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.
Support this project
Selfdestruct is free, always, for everyone — every security property on this page included. If it's been useful to you and you'd like to help cover hosting costs, you can leave a small contribution on Ko-fi. It's entirely optional and doesn't unlock or change anything — just a thank-you that helps keep the lights on.
Get in touch
Questions, a security issue to report, or something on this page that doesn't hold up — info@selfdestruct.online.