Learn · Practical guides
Self-destructing messages: what they can and can't promise
What a self-destructing message can honestly promise, how messenger timers, one-time note sites and cipher.ink compare, and six questions to ask of any of them.
A self-destructing message can honestly promise one thing: the service won't keep its copy past a timer or the first read. It can't promise that the recipient didn't copy, photograph or forward what they read. Signal says as much about its own disappearing messages, which it describes as not for "situations where your contact is your adversary". This page explains what these tools do, compares three approaches fairly, and lists what to ask of any of them. Facts about other products carry the date they were checked.
What "self-destructing" covers
Three separate promises get mixed together, and it helps to pull them apart:
- The sender's and the service's copies are removed. A server deletes the stored message after it's read or after a time limit. This part works, and it's the part that matters for privacy, because it keeps a secret from sitting in someone's archive for years.
- The recipient's copy goes away. A messaging app can delete the message from the recipient's phone after a timer. That works only while the recipient's app cooperates.
- The recipient can't keep a copy. Nothing can promise this. A person can photograph the screen with another device, copy the text before it vanishes or write it down.
The first is real, the second is a convenience, and the third doesn't exist. A tool that implies the third is overselling. The useful question is who you're protecting the message from: the service, a future breach of an archive, someone who later picks up a device, or the person you sent it to. The feature is built for the first three.
Three approaches
Disappearing messages inside a messenger
Messengers such as Signal let each conversation set a timer after which messages are deleted from every device in it. Signal's help center (checked October 23, 2026) says the timer for a message you send starts after you send it, and for a message you receive starts after you've read it. Its blog describes the range as five seconds to a week, while the current help article describes custom times of up to four weeks. Anyone in the chat can change the timer, and in groups, administrators can limit who can. You have to set it before sending, and it covers only messages sent after the setting was made. The messages are end-to-end encrypted by default, so the service can't read them while they exist, and the message deletes itself on every device that follows the rules.
One-time note websites
Sites and tools of this kind let you type a note, give you a link and delete the note once it's opened. They differ a great deal, so check each one against the points listed below. Some encrypt in the browser and keep the key out of the server's reach, some encrypt only on the server, and some don't encrypt at all. Their big advantage is that the recipient needs nothing but a browser.
cipher.ink
cipher.ink is one of these link-based tools, with a particular design. The message is encrypted in the browser with AES-GCM (AES-GCM explained), with a key from either a passphrase or the link itself, and the server stores only ciphertext. You can set the message to be deleted after 10 minutes, an hour, a day, a week (the default), 30 days or never, and to burn after reading, which deletes it from the server the moment it's opened (how burn after reading works). You get a private read receipt that shows whether it's been opened, and the page counts an open only when someone actually unseals it, not when a chat app previews the link. It also takes attachments up to MB.
Side by side
This compares properties, not quality, since a messenger and a link tool do different jobs. Facts about Signal come from its own documentation, checked October 23, 2026. The column for note sites in general describes what varies, because no single description fits all of them.
| Disappearing messages in Signal | One-time note sites in general | cipher.ink | |
|---|---|---|---|
| The recipient needs | The app and an account | A browser | A browser |
| You need | The app and an account | Nothing, usually | Nothing: no account, no sign-up |
| Encrypted end to end | Yes, by default | Varies: check where the encryption happens | Encrypted in the browser; the server stores only ciphertext |
| Where the decryption key goes | Stays on the devices | Varies | In the passphrase you share, or after the # in the link, which browsers do not send to the server |
| Deletion trigger | A timer per conversation, from 5 seconds up to 4 weeks (after sending, or after the recipient reads it) | Usually after the first read; sometimes a timer | Burn on first open, or a timer of 10 minutes to 30 days, or never |
| You can tell whether it was read | Read receipts, if both people enable them | Varies | A private receipt link and a list of your messages in this browser |
| Fits | An ongoing conversation | A one-off secret | A one-off secret or document |
| The limit everyone shares | The recipient can copy or photograph it | The same | The same |
One difference deserves plain words. The web isn't a program you install. When you encrypt with a web tool, the page's code comes from the site every time, so you're trusting the site not to send you changed code. A messenger installed from a store and checked for tampering doesn't have that weakness in the same way. The security page lists this limit and the others for cipher.ink.
What to ask of any self-destructing tool
- Where does the encryption happen, and who has the key? If the service can decrypt, "self-destructing" is a promise of good behavior, not a property of the design.
- What is deleted, when and from where? A server record, backups and the recipient's device are different things.
- What does the service keep afterwards? Metadata (who, when, size) can outlast the content.
- Does a link preview burn the message? Chat apps fetch links to show a preview. A tool that counts that as a read destroys the message before the person sees it.
- Can the recipient save it? If the tool offers a "save" button, the deletion promise covers only the server.
- Is the design published and testable? You should be able to read how it works, not just a marketing claim.
Picking one
For a conversation, use an end-to-end encrypted messenger and turn on disappearing messages for sensitive chats (what end-to-end encryption means). For a one-off secret to someone who won't install anything, such as a password, a code or a scan, a link tool is simpler. Write it, set it to burn, and send the passphrase by a different route (how to send a password securely). With either, assume the person on the other end can keep what you tell them, and send only what you could live with.
Common questions
Can a self-destructing message be recovered after it's deleted?
From the service, not if it has really deleted it and never held the key. From the recipient's device, perhaps, via a backup, a notification history, a screenshot or a photo of the screen.
Is it safe to rely on disappearing messages for legal or high-risk secrets?
They reduce what's stored, which is useful, but they're no guarantee against the person you wrote to. For high-risk situations, think about who might get the message and how, and read the advice of a security organization that specializes in your situation. This page isn't legal advice.
Why does my link preview "burn" a note?
Some chat apps and email scanners open links to build previews or check for malware. A tool that deletes a note on any request loses it to the preview. cipher.ink avoids this by deleting only after a person actually decrypts the message.