Your files never leave your device. All processing happens locally in your browser.
How do I send a self-destructing, burn-after-reading message?
Type your message into Self-Destruct Message and it is encrypted in your browser with AES-256-GCM. The ciphertext — with an optional expiry timestamp and a per-device view budget baked in — is packed into the link’s URL fragment (the part after #), which browsers never send to a server. When the recipient opens the link it decrypts locally, shows a live expiry countdown, and after it is read the tool hides it on that device so re-opening shows “already destroyed”. Everything runs 100% client-side with no backend, so the self-destruct is best-effort, not a server guarantee.
AES-256-GCM authenticated encryption via the Web Crypto API — random key or PBKDF2-HMAC-SHA-256 passphrase
The ciphertext rides in the URL #fragment, which is never transmitted to a server
Optional expiry (15 min–30 days) is embedded in the payload and checked by the reader with a live countdown
Burn-after-reading hides the message on a device after it is read; “burn now” clears it manually
Honest: with no backend the burn and expiry are enforced only in the reader’s browser, not by a server
What is
Self-destructing (burn-after-reading) message
A self-destructing message is a private note designed to become unavailable after it is read once or after an expiry time. This tool builds a no-backend version: it encrypts the message in the browser with AES-256-GCM and stores the whole ciphertext, plus an optional expiry timestamp and view budget, in the URL fragment (after the # symbol), which browsers never include in the HTTP request. The reader page decrypts locally, enforces the expiry with a client-side countdown, and writes a non-reversible fingerprint to localStorage so the message is hidden on that device after it is viewed. Because there is no server to store and delete the ciphertext, the “self-destruct” is best-effort and device-local rather than a true server-enforced burn.
Security & Privacy
Related terms
AES-256-GCMburn after readingone-time secretURL fragmentPBKDF2end-to-end encryptionephemeral messagePrivateBinOneTimeSecretzero-knowledgeexpiring link
Frequently Asked Questions
No. The message is encrypted in your browser and the ciphertext rides in the URL fragment, which browsers never send to a server.
Encryption happens entirely on your device with the browser’s Web Crypto API. The encrypted payload — including the optional expiry — is stored in the URL fragment, the part after the #, which browsers do not include in the HTTP request, servers and proxies do not log, and the Referer header strips. There is no backend, database, upload or CDN in the crypto path, and no analytics; the message lives only in the link and, briefly, the clipboard.
Best-effort only. With no backend the burn is enforced in the reader’s browser on the device that opened it — the same link still decrypts on another device.
A true burn-after-read needs a server to store the ciphertext and delete it after the first fetch. This tool has no server, so the encrypted message lives inside the link itself. After the recipient reads it, the tool writes a fingerprint to that browser’s localStorage and hides the message, so re-opening on the same device shows “already viewed and destroyed”. But anyone who still has the link (and passphrase) can decrypt it on a different device, or before it is ever opened. For guaranteed one-time access, use a hosted service such as onetimesecret.com or a self-hosted PrivateBin.
The expiry timestamp is encrypted into the link and checked by the reader’s clock. It is a client-side check, not a server-enforced deletion.
When you set an expiry, that timestamp is placed inside the encrypted payload before it becomes a link. The reader page decrypts it, compares it to the device’s clock, shows a live countdown while the message is valid, and refuses to display the message once the time has passed. Because there is no backend, nothing is actually deleted at expiry and a determined holder could ignore the check or set their clock back — treat it as a courtesy limit, not a security guarantee.
A random-key link opens instantly (the key is in the link); a passphrase link keeps the key out of the URL as a second factor you share separately.
In random-key mode a fresh 256-bit AES key is generated and packed into the link, so anyone with the full link can open it — treat the whole link as the secret. In passphrase mode the key is derived from a passphrase with PBKDF2-HMAC-SHA-256 and only the ciphertext is in the link; the recipient must also type the passphrase, which you send over a different channel. A leaked passphrase-mode link alone cannot be decrypted, so it is the better choice for anything sensitive. Either way, send the link privately and delete it after use.
Detailed Explanation
📖How It Works
What This Tool Does
Self-Destruct Message is a 100% client-side tool for sending a private note as an encrypted, burn-after-reading link. A pure engine (selfDestructEngine.ts) wraps the message in a small versioned envelope carrying an optional expiry timestamp and a per-device view budget, encrypts the whole thing in the browser with AES-256-GCM, and packs the ciphertext into the URL fragment (the part after #), which browsers never send to a server. The recipient opens the link and it decrypts locally with a live countdown; after it is read the tool hides it on that device. There is no backend, no upload and no database — the link itself is the encrypted message.
Encrypts a message in the browser with AES-256-GCM (Web Crypto API)
Optional expiry and view budget are baked into the payload before encryption
The encrypted payload rides in the URL #fragment, never transmitted to a server
Reader decrypts locally with a live countdown, copy-and-burn and burn-now
No backend, no upload, no CDN in the crypto path
⚙️Methodology
How the Envelope and Two Modes Work
Before encryption the engine prepends the message with a small JSON envelope { message, createdAt, expiresAt, maxViews, burnAfterReading }, then reuses the audited fragment-encryption engine (secretShareEngine.ts on textCryptoEngine.ts). In random-key mode a fresh 256-bit AES key is generated with crypto.getRandomValues and iv ‖ rawKey ‖ ciphertext+tag is base64url-encoded into the fragment as #s1k.…, so the link opens with no passphrase. In passphrase mode PBKDF2-HMAC-SHA-256 stretches the passphrase over a random salt into the AES key and only version ‖ iterations ‖ salt ‖ iv ‖ ciphertext+tag is placed in the fragment as #s1p.… — the passphrase is never in the link. GCM is authenticated, so a wrong key or any tampering fails to decrypt.
Passphrase: #s1p.base64url(version ‖ iterations ‖ salt ‖ iv ‖ ciphertext+tag)
PBKDF2-HMAC-SHA-256 key stretching; iteration count stored in the payload
AES-GCM authentication tag detects tampering or a wrong passphrase
🔧Technical Details
How the Burn and Countdown Are Enforced
The reader page reads window.location.hash, decrypts the envelope locally, and enforces its rules in the browser. Expiry is a client-side clock check: the reader compares the embedded expiresAt to the device clock, renders a live countdown while the message is valid, and refuses to display it once the time has passed. Burn-after-reading is tracked per device: the engine computes a SHA-256 fingerprint of the fragment and, after a successful view, writes it to localStorage with a view count; once the view budget is spent (or the user presses burn-now) it records a burnedAt time, so reopening on that device shows “already viewed and destroyed” instead of the message. None of this touches the network, and all randomness comes from crypto.getRandomValues.
Expiry compares an embedded timestamp to the device clock — a live countdown, then hidden
Per-device burn keyed by a SHA-256 fingerprint of the fragment in localStorage
A view budget allows N reads on a device before it is hidden
Burn-now and copy-and-burn clear the message immediately on the device
Fragments are never part of the HTTP request — servers cannot log them
⚠️Limitations
Honest Limitations
This is end-to-end encrypted but it is not a true one-time or self-destructing secret. Because there is no backend to store and delete the ciphertext, anyone holding the full link can decrypt it on a different device, or before it is ever opened, and the expiry is a client-side clock check that a determined holder could ignore or defeat by setting their clock back. The burn and “destroyed” state are stored on the opening device only and cannot stop another device from opening the same link. URLs may also be retained in browser history, chat link previews and security scanners, and in random-key mode the key is inside the link, so a leaked link is a leaked message. For guaranteed burn-after-read and server-enforced expiry, use a hosted service such as onetimesecret.com or a self-hosted PrivateBin, and share the link and (in passphrase mode) the passphrase over different channels.
No backend → the burn and expiry are best-effort, not server-enforced
Anyone with the full link can decrypt it on another device before it burns
Expiry is a client-side clock check, not a deletion
The destroyed flag is per-device only, not a global lock
Random-key links: the link itself is the message — share privately
🔒Privacy & Security
Private by Design
The message is encrypted entirely on the user’s device with the browser’s Web Crypto API, and the ciphertext, with its optional expiry, is stored only in the URL fragment, which is never sent to a server. There is no upload, no database, no logging, no server and no CDN in the crypto path, and no analytics or telemetry anywhere in the tool. The message exists only in the link and, briefly, the clipboard; the reader offers copy-and-burn and burn-now actions and can strip the link from the current tab. The tool works offline once cached, supports dark mode and a mobile-first layout, and the only optional network use anywhere on the site is consent-gated ads, which never see the message.
Encryption runs locally — nothing uploaded, logged or stored on a server
Ciphertext and expiry live only in the #fragment and the clipboard
No server, no CDN, no analytics in the crypto path
Copy-and-burn, burn-now and a per-device destroyed flag for the reader
Works offline once cached; dark-mode and mobile-first
Client-side self-destruct vs a hosted burn service
Aspect
This tool (no backend)
Hosted service (PrivateBin / OneTimeSecret)
Where the ciphertext lives
In the URL #fragment only
On a server, deleted after first fetch
Burn-after-read
Best-effort, per-device (localStorage)
Server-enforced — deleted globally on read
Expiry
Client-side clock check embedded in the link
Server deletes the record at expiry
Data uploaded
Nothing — encrypted in the browser
Ciphertext uploaded (some services see plaintext)
Best for
Quick, no-account private notes
Guaranteed one-time access for high-stakes secrets
This tool is end-to-end encrypted and 100% client-side, but with no backend the self-destruct and expiry are best-effort, not guaranteed. For server-enforced burn + expiry use a hosted service. As of July 2026.
