What is a self-destructing link?
A self-destructing link (also called a self-destruct link, one-time link, or disappearing link) is a URL that reveals its content exactly once. The moment the recipient opens it, the underlying data is permanently deleted from the server. There is no cache, no backup, no second read — the link becomes a dead 404 the instant it is used.
1time.io generates self-destructing links that are end-to-end encrypted in your browser using AES-256-GCM. The decryption key lives in the URL fragment and never touches the server, so even we cannot read what you share. Paste a secret above, hit the button, and copy the one-time link — that is the whole flow.
The Concept: Why Messages Should Self-Destruct
Most digital messages live forever by default. Emails sit in inboxes for years. Slack messages are searchable indefinitely. Text messages get backed up to cloud services. This persistence creates a massive attack surface — every stored message is a potential leak in a future breach.
Self-destructing messages flip this model. Instead of storing data by default and hoping it stays safe, they delete data by default and only make it available for the minimum time needed. This is the principle of data minimization — you cannot leak what you do not store.
The Three Types of "Disappearing" Messages
Not all self-destructing messages work the same way. There are three distinct approaches, and they offer very different levels of actual privacy.
Type 1: Timer-Based Deletion (Weakest)
Apps like Snapchat and Instagram use timer-based deletion. The message displays for a set number of seconds, then the app hides it from the interface. The problem? The data often persists on the server, in backups, in device caches, or in notification logs. Screenshots capture it trivially. This is UI-level deletion, not data-level deletion.
Type 2: Time-to-Live Server Deletion (Better)
Services like Signal and Telegram (secret chats) delete messages from their servers after a set period. This is more robust — the data actually gets removed from the server. But the message still exists on both devices until the timer expires, and the sender has no control over what happens on the recipient device.
Type 3: One-Time Access with Immediate Deletion (Strongest)
This is the approach used by one-time secret sharing tools. The message can only be accessed once. The moment the recipient reads it, the server permanently deletes the encrypted data. There is no window of vulnerability, no timer to beat, no second chance. Read once, gone forever.
| Feature | Timer-Based | TTL Server | One-Time Access |
|---|---|---|---|
| Deleted from server | ✗ Often retained | ✓ After timer | ✓ Immediately |
| Screenshot-proof | ✗ | ✗ | ✗ |
| End-to-end encrypted | ✗ Usually not | ✓ Some apps | ✓ Always |
| Zero-knowledge server | ✗ | ~ Varies | ✓ |
| No account needed | ✗ | ✗ | ✓ |
Under the Hood: How 1time.io Self-Destructs
Let us walk through exactly what happens when you create and share a self-destructing message on 1time.io, step by step.
The Key Insight: Separation of Key and Data
The critical design principle is that the encryption key never touches the server. It lives only in the URL fragment (the part after the #symbol), which browsers do not send to servers. The server stores only meaningless ciphertext — even if the server is compromised, the attacker gets encrypted gibberish with no way to decrypt it.
Why the URL hash matters: When you visit example.com/v/#secretkey, your browser sends a request for /v/ to the server. The #secretkey part stays entirely in the browser. This is a fundamental web standard, not a workaround — it is how URL fragments have always worked.
What "Zero-Knowledge" Really Means
The term gets thrown around a lot, so let us be precise. A zero-knowledge architecture means:
- The server never sees the plaintext. Encryption and decryption happen exclusively in the browser using the Web Crypto API.
- The server never sees the encryption key. It is embedded in the URL fragment, which is never transmitted to the server.
- Even the service operator cannot read your messages. There is no master key, no admin backdoor, no way to "recover" a lost secret.
- The source code proves it. Open-source tools let anyone verify these claims by reading the code.
The Limits of Self-Destruction
No self-destructing message system is perfect. Here is what even the best implementations cannot prevent:
- Screenshots. Once the recipient sees the message, they can take a screenshot. No technology prevents this.
- Copy-paste. The recipient can copy the decrypted text before the page is closed.
- Compromised devices. If the recipient device has malware or a keylogger, the secret is exposed regardless of encryption.
This is why self-destructing messages are a risk reduction tool, not an absolute guarantee. They dramatically reduce the window of exposure and eliminate the permanent storage risk, but they cannot control what happens after the message is displayed on a screen.
Be wary of apps that claim to be "screenshot-proof." Any app that claims it can prevent screenshots is either misleading you or relies on easily-bypassed device restrictions. The honest approach is to acknowledge this limitation and focus on what can actually be secured: the transmission and storage of data.
When to Use Self-Destructing Messages
Self-destructing messages are ideal for sharing data that is needed once and should not persist:
- Passwords and login credentials
- API keys and access tokens
- Two-factor authentication backup codes
- SSH keys and certificates
- Sensitive personal information (SSNs, account numbers)
- Temporary access codes or PINs
Frequently asked questions about self-destructing links
What is a self-destructing link?
A self-destructing link is a URL that reveals its content exactly once. The moment the recipient opens it, the underlying data is permanently deleted from the server and the same link becomes a dead 404 forever after. 1time.io generates free self-destructing links that are end-to-end encrypted in your browser.
How do I create a self-destructing link?
Paste your secret into the form at the top of this page, click the button to generate a one-time link, and copy it. Share the link with your recipient. When they open it, the secret is decrypted in their browser and the server immediately deletes the encrypted data. No signup, no account, free.
How long does a self-destructing link last?
A self-destructing link expires the instant it is read — that is the "self-destruct" trigger. As a safety net, unread links also auto-expire after a configurable window (1 to 30 days on 1time.io) so nothing sits on the server forever if the recipient never opens it.
Is the self-destructing link generator free?
Yes. 1time.io is free and open source (MIT licensed). There is no paid tier, no signup, no usage limits for normal sharing, and no ads. You can also self-host the source code from GitHub if you want full control.
Can a self-destructing link be recovered after it is read?
No. Once the recipient opens the link, the ciphertext is deleted from the server and cannot be restored. There is no admin backdoor, no backup, and no recovery path — even we cannot retrieve it. If you lose access, you have to create a new link.
Are self-destructing links really deleted or just hidden?
On 1time.io, the encrypted blob is deleted from the database at the moment of first read — not hidden, not archived, not flagged. The server never saw the plaintext in the first place because encryption happens in your browser and the decryption key lives only in the URL fragment, which is never transmitted to the server.
Can I send a self-destructing link from the terminal?
Yes. 1time.io ships a CLI you can install with `npm install -g @1time/cli`. Use `printf 'secret' | 1time send` to generate a self-destructing link directly from your shell or a CI/CD pipeline.
Generate a self-destructing link
End-to-end encrypted, zero-knowledge, destroyed after one read. Free, no signup.
Create a self-destructing link