One link. One read. Then it's gone. No account, no app install, no copy sitting on a server forever.
Paste your message into textdrop.sh, toggle burn-after-read, and send the link. The first person to open it sees the message. The next click hits a deleted-paste page.
Type your message, hit Share, send the link. It dies on first read.
Most messaging platforms keep messages forever by default. Slack indexes them. Email backs them up. iMessage sticks them in iCloud. Even "disappearing" messages in chat apps usually rely on the recipient's app cooperating.
A self-destructing paste is server-enforced. The deletion happens on textdrop.sh in the same Redis transaction as the read. There's no window where two clients could both grab it. Once read, the bytes are unrecoverable, even by us.
It still expires on the timer you set. Pick anything from a few minutes to a week. After the expiry, the paste is deleted whether it was opened or not.
No. With burn-after-read on, the very first successful open atomically deletes the paste. The second click hits a 'this paste is gone' page.
textdrop.sh fetches metadata separately from ciphertext, so link unfurls in chat clients do not consume the burn. The paste only burns when the recipient actually opens it in a browser.
Yes. Self-destructing messages stop the paste from being archived on a server. They do not stop a determined recipient from copying it. Use this for things you want gone, not things you need to control.
If you also turn on a password, yes. The password is required to decrypt and is never sent to the server. Without a password, the content is encrypted but the key is held server-side so it can be retrieved by link alone.