One-Time Secret Links
Share sensitive information without leaving a permanent record
Email, WhatsApp, Facebook Messenger, and Slack were built to keep messages forever. Some secrets were never meant to persist. Here's how one-time encrypted links work, when to use them, and why burn after reading is a security feature—not a gimmick.
Key takeaways
- One-time links are for ephemeral delivery, not long-term storage.
- Burn-after-read reduces leftover copies in chat and email archives.
- Combine short TTL with least privilege and post-handoff rotation.
- Confirm the right recipient before you send the link.
Most people share sensitive information the same way they share everything else: paste it into an email, drop it in Slack, or send a text.
That works until you realize what you've actually done. You didn't just deliver a password or API key—you created a permanent record in someone else's inbox, your company's chat archive, a cloud backup, a compliance export, or an AI-generated meeting summary you forgot existed.
When the Musk v. Altman trial opened in 2026, prosecutors introduced text messages between Sam Altman and Mira Murati from his November 2023 ouster at OpenAI. Chats that felt private in the moment—hurried updates about board calls and a path back—became federal exhibits. The problem was not interception. It was retention.
Some information has a short job to do. A staging password. A recovery code. A one-time access instruction. A contractor credential that expires Friday. These secrets don't need a searchable history. They need to arrive, get used, and disappear.
That's what one-time secret links are for.
The Problem with "Secure Enough" Channels
Email can be encrypted in transit. Slack can be locked down with single sign-on (SSO). Signal can offer disappearing messages. All of that helps—but it solves a different problem.
The issue isn't always interception. It's retention.
When you send a secret through a normal channel, you're betting on a massive chain of assumptions:
- The message will never be forwarded, screenshotted, or copied.
- Nobody will accidentally search the shared chat history six months later.
- Backups, server exports, and data discovery workflows won't turn a quick handoff into a long-term liability.
- Link preview bots in Slack, Teams, or iMessage won't fetch the URL automatically and burn it before your recipient opens it.
- The secret will be immediately rotated after use, even though the old value still sits in a server log somewhere.
The Separation of Powers: Encryption protects content in motion. Ephemerality reduces what exists afterward. Both matter—but most mainstream communication tools optimize heavily for the first and entirely ignore the second.
What a One-Time Secret Link Actually Is
A one-time secret link (sometimes called a "burn after reading" link or self-destructing note) is a URL meant to deliver sensitive text to one reader, once. After that read, the content should be gone—not archived, not searchable, not lingering in a mailbox or chat history.
A true one-time secret design is stricter than an expiry timer. Critically, the encryption key is generated in your browser—never on the server—and the plaintext is encrypted there before anything is uploaded.
Step 1: Your Browser
Browser-Generated Key & Encryption
You write the secret in your web browser. The browser generates a fresh encryption key locally and uses it to encrypt the text—before any network request leaves your device.
Step 2: The Server
Ciphertext Upload
Only the encrypted blob is uploaded. The server stores ciphertext it cannot read because it never received the key or the plaintext.
Step 3: The URL
Key Stays in the Link
The browser-generated key is appended to the link in the URL fragment—the part after #—which is never sent to the server.
Step 4: The Recipient
One Read, Then Gone
The recipient opens the full link. Their browser reads the key from the fragment, decrypts locally, and the server deletes the ciphertext after that first successful read.
Not every product sold as a one-time secret link follows this pattern. Some tools encrypt on the server after receiving your text—or generate the key there, meaning the service could read your secret. Others rely on a shared password the service can validate. Still others delete on a schedule but keep metadata, logs, or recoverable copies. When you evaluate a tool, ask whether it implements the full design—not only whether the link expires.
Why the URL Fragment Matters
This architectural detail is incredibly easy to miss, yet it is the foundation of modern web cryptography.
In a standard HTTPS request, everything before the # symbol is sent directly to the server. Everything after the # stays inside the browser sandbox. That means a well-designed one-time link system can store your encrypted content securely at /note/abc123 while keeping the decryption key at #xK9m2p... entirely invisible to the server logs, CDN access paths, or external database tables.
When to Use a One-Time Link (And When Not To)
Not every channel is wrong for every kind of secret—but most everyday tools were built for persistence, not one-time delivery.
| Channel Type | Encrypted? | Persistent? | Good for One-Time Secrets? |
|---|---|---|---|
| Often in transit | Yes—forever, in multiple boxes | ✗ Poor | |
| Slack / Teams | Yes, on platform | Yes—searchable, exportable | ✗ Poor |
| SMS / iMessage | Varies widely | Often backed up, cloud-synced | ✗ Poor |
| Password Manager | Yes | Designed specifically for retention | Usually cumbersome—often paid, high-friction for quick handoffs |
| Signal / WhatsApp (disappearing) | Yes, end-to-end | Messages vanish on a timer | Good fit—but both sides need accounts |
| One-Time Link | Yes, client-side | Deleted instantly after read | ✓ Built for this |
Good Fits
- Passwords, API keys, and temporary tokens being handed to one person once.
- System recovery codes and 2FA backup secrets.
- Temporary physical access instructions ("use this door code until 6 PM").
- Legal- or HR-sensitive drafts that aren't meant to become institutional memory.
Poor Fits
- Long-term storage: Use a designated password manager vault.
- Ongoing conversations: Use an end-to-end encrypted messaging app like Signal.
- Auditable secrets: If compliance dictates an unchangeable trail, use your organization's approved vaulting system.
The Link Preview Trap
Here's a failure mode most tech teams discover the hard way. Many enterprise chat apps automatically crawl incoming URLs to generate rich previews (titles, descriptions, thumbnails).
That automatic crawl can consume a one-time link before your recipient even has a chance to click it. The automated preview bot becomes the first reader, the note burns, and your colleague opens a dead link.
Serious ephemerality tools actively mitigate this by blocking known crawler user-agents, forcing explicit user click-throughs before local decryption happens, and keeping token expiries incredibly tight.
Where PrivateNote Fits
PrivateNote is engineered around this client-side encryption model. It isn't a long-term password vault, a team wiki, or a permanent compliance archive. It is a lean, lightning-fast utility designed for delivery.
For larger files that need the same client-side encryption model, Encrypt.lu applies the same architectural approach at file scale.
It ensures that the lifespan of your sensitive data matches the lifespan of the medium it is traveling through. Because sometimes, the most secure message is the one that completely stops existing.
How It Works