How it works
A one-time secret link is a URL that contains sensitive information — a password, an API key, a private note — that can only be opened once. The moment the link is accessed, the underlying data is permanently deleted from the server. Open it a second time and there is nothing left to retrieve. This guide explains the concept, the technical mechanics behind it, and why it is more secure than the alternatives.
The concept comes from a simple observation: the safest version of a shared secret is one that stops existing the moment it has been received.
When you send a password over email, you create a persistent record. That record sits in sent folders, inboxes, and mail server archives indefinitely. It can be found months or years later if either party's account is compromised. The credential outlives the reason it was shared.
A one-time link inverts this. The secret exists only until the moment it is read — and then it is gone permanently. There is no archive, no copy, no residual record of the plaintext. This is sometimes described as “burn after reading” — a concept from intelligence tradecraft, where documents were physically destroyed after being read to prevent them from falling into the wrong hands.
A well-implemented one-time link is not just ephemeral — it is also encrypted, with a zero-knowledge architecture. CYPH3RDROP's implementation works as follows:
When you enter a secret, your browser generates a random 256-bit encryption key locally. This key exists only in your browser's memory at this point.
Your secret is encrypted using AES-256-GCM — entirely on your device, before anything is transmitted. AES-256-GCM is an authenticated encryption algorithm used by governments, financial institutions, and security-critical applications worldwide. The algorithm produces ciphertext plus an authentication tag, which ensures the ciphertext cannot be tampered with without detection. The encryption happens in your browser using the Web Crypto API, a native browser interface for cryptographic operations.
Only the encrypted ciphertext (plus the randomly generated 96-bit initialisation vector used in encryption) is sent to the server. The server stores this blob. Without the decryption key, it is meaningless — mathematically indistinguishable from random noise.
A one-time link is generated. The decryption key is placed in the URL fragment — the portion of a URL after the # symbol. Browsers have a specific behaviour with URL fragments: they never include the fragment when sending HTTP requests. This means the server never sees the decryption key. Not when the link is created, and not when the link is opened.
When the recipient opens the link, their browser sends a request containing the identifier (not the key). The server retrieves the ciphertext and, in the same operation, permanently deletes it. This is an atomic operation: retrieve and delete happen together, so there is no window in which two requests could both successfully retrieve the same ciphertext.
The recipient's browser decrypts the ciphertext locally using the key from the URL fragment. The plaintext secret is displayed on screen. At this point, the ciphertext on the server no longer exists.
Why the URL fragment matters
The URL fragment — everything after the #— is a browser-only value. It is never included in HTTP requests sent to the server. Even CYPH3RDROP's own servers never see the decryption key. If our servers were breached tomorrow, an attacker would find only encrypted ciphertext — meaningless without keys that were never stored anywhere on our end.
Zero-knowledge means the service operator — in this case, CYPH3RDROP — has no ability to read the secrets stored on their servers. This is not a policy claim. It is a technical property enforced by the architecture.
The server stores ciphertext. The decryption keys are never transmitted to the server. Even if CYPH3RDROP's database were breached completely, an attacker would find only encrypted blobs with no keys. The secrets would be unreadable.
This is meaningfully different from services that store secrets “securely” but hold the encryption keys themselves. If the service holds the keys, a breach, a subpoena, or a rogue employee can potentially expose your data. Zero-knowledge architecture removes that possibility.
| Method | Encrypted at rest | Deleted after reading | Zero-knowledge | No persistent copy |
|---|---|---|---|---|
| One-time encrypted link | ✓ | ✓ | ✓ | ✓ |
| ✗ | ✗ | ✗ | ✗ | |
| Slack DM | Partial | ✗ | ✗ | ✗ |
| SMS | ✗ | ✗ | ✗ | ✗ |
| Password manager share | ✓ | ✗ | Varies | ✗ |
Email, chat, and SMS all store messages persistently. None of them delete the message after it is read. Most are not zero-knowledge — the service provider can read your messages if required. A one-time link is the only common method that checks all four boxes.
One-time links have an important secondary property: they are tamper-evident. If someone intercepts the link and opens it before the intended recipient, the link is already burned by the time the recipient tries to open it. The recipient sees an error — the link is dead or expired.
This is a signal. A dead link that should not be dead tells the recipient that someone else opened it. It prompts them to alert you, and gives you the opportunity to rotate the credential before it is used maliciously. Email has no equivalent property — if someone reads an email in transit, the recipient still receives it looking completely normal.
No. The server never has the decryption key. The key lives in the URL fragment, which is never transmitted to the server. The server could retain the ciphertext indefinitely — but without the key, it cannot decrypt it. The zero-knowledge property holds regardless of server behaviour.
The retrieval and deletion are atomic. If two requests arrive at the same moment, one will successfully retrieve the ciphertext and one will receive a “not found” response. It is not possible for both to succeed.
CYPH3RDROP automatically expires and permanently deletes unopened secrets after 7 days. After that window, the ciphertext is gone from the server regardless of whether anyone ever opened it.
Yes. The Web Crypto API is available in all modern browsers on iOS and Android. Both creating and opening links works on mobile without any additional apps or software.
Try it yourself
Create a one-time encrypted link in seconds. No account, no sign-up.
Create a secret link →