One-Time Secret Link
Send private information that disappears.
Share passwords, API keys, private messages, files, and audio recordings with an encrypted, temporary link. Your browser encrypts the content before it leaves your device, and you choose when the link expires and how many times the note can be opened.
Encrypted in your browser. The decryption key never reaches our server. The recipient does not need an account.
Key takeaways
- A one-time secret link is for temporary handoff, not storage or conversation.
- Encryption protects access; expiry and one-time reveal reduce leftover copies.
- Security depends on the implementation and how the link is sent—not on the name.
- Confirm the recipient, keep expiry short, and rotate credentials after use.
The recipient opens a one-time link to read a private message, listen to audio, or access shared files in their browser. The note becomes unavailable when its open limit is reached or it expires. Files and recordings have a separate, limited access window after reveal, so they can finish downloading or playing.
Use it for passwords, API keys, recovery codes, private messages, documents, photos, and audio recordings that need to reach someone without becoming a permanent email attachment or chat upload. Secure file sharing uses the same idea: send an encrypted, temporary link rather than leave the original content in a conversation.
The issue isn’t always interception. It’s retention. Encryption protects information against unauthorized access. Ephemerality reduces how long unnecessary copies remain available. A one-time secret link is built for a third job: temporary handoff.
What is a one-time secret link?
Services use several names for the same idea: one-time link, secret link, one-time note, burn-after-reading link, self-destructing note, or expiring secret link. The label varies. The security properties do not automatically follow from the name.
A product called a “one-time secret” does not, by itself, mean encryption happens in the browser, that the provider cannot decrypt the payload, that the key is withheld from the server, that deletion happens immediately after a read, or that metadata disappears. Those are design choices. When you evaluate a tool, inspect the properties—not the marketing term.
A useful checklist is: where is the plaintext encrypted? Does the server ever receive the decryption key? What happens after the intended retrieval? How long does an unused link remain available? What does a chat preview fetch if someone pastes the URL?
How does a one-time secret link work?
In PrivateNote, your browser encrypts the message and any attached files or audio before upload. The server stores encrypted data, and the recipient’s browser decrypts it locally when they reveal the note. Note text uses AES-256-GCM via the Web Crypto API; attachments are encrypted separately so they can be fetched during their own access window.
Not every product sold as a one-time secret link follows this pattern. Some encrypt on the server after receiving your text, or generate the key there, which means the service could read the secret. Others delete on a schedule but keep recoverable copies. Ask whether the full design is implemented—not only whether the link expires.
For PrivateNote’s encryption architecture, including password wrapping with Argon2id, see How It Works.
Why the URL fragment matters
This detail is easy to miss, and it is the foundation of this architecture.
In a normal HTTPS navigation, the browser sends the path and query to the server. The URL fragment—everything after #—stays in the browser and is not included in that request. A well-designed system can therefore store ciphertext at a note identifier such as `/note/abc123` while keeping decryption material in `#…`, out of ordinary server logs for that page load.
Putting a key after # does not, by itself, make an application secure. The surrounding cryptography still has to be sound: a strong random key, authenticated encryption, and a server that never needs the plaintext. The fragment is how those pieces stay separated—not a shortcut around them.
One-time link vs. expiring link vs. disappearing message
These ideas are often mixed together. They are different controls, and a single product can combine them.
- One-time link — Availability depends primarily on access. On PrivateNote, a successful reveal counts toward the note’s open limit. Reaching that limit makes the note unavailable for another reveal; attached files and audio follow their separate access window.
- Expiring link — Availability depends primarily on time. The link remains retrievable until the clock runs out, whether or not anyone opened it.
- Disappearing message — Part of an ongoing conversation. Retention follows the messenger’s policy, which may still leave backups, quoted replies, or device copies.
PrivateNote combines both access and time. New notes default to one successful reveal, and they also expire if unused—one day by default, with shorter or longer presets depending on the plan. Files and audio have a separate access window after reveal. These limits control future access; they do not erase copies the recipient has already saved.
Are one-time secret links secure?
They can be. Security depends on the implementation and on how the link is used—not on the phrase “one-time.”
A serious design should consider client-side encryption, strong random keys, what the server can see, expiry, access semantics, optional password protection, optional recipient verification, metadata, link leakage, endpoint compromise, and recipient behavior.
PrivateNote encrypts in the browser, stores ciphertext, keeps the key in the URL fragment, defaults to a single reveal, and expires unused notes. You can add a password or, on paid plans, recipient verification when the sensitivity warrants it. Recipients do not need an account.
A one-time link does not protect against a compromised sender or recipient device, a recipient who copies the secret after viewing it, screenshots or photos of the screen, or sending the complete URL—including the fragment—to the wrong person. Treat the full link as the capability.
When should you use a one-time link?
Use one when a secret has a short job: arrive, be used, and stop living in the channel you used to send it.
Passwords
A one-time link is a good fit for handing a temporary or newly created password to one recipient without leaving the plaintext in mail or chat history. For the password-specific workflow, see how to share a password securely.
API keys and tokens
Developers and contractors often need a key once. Sending it through a link keeps the raw credential out of Slack threads, tickets, and Git comments. See how to share an API key securely.
Recovery codes
Useful when a backup or 2FA recovery code genuinely needs to move to another authorized person—and should not remain searchable in the thread that carried it.
Private messages
Information that needs to be communicated once, without becoming a permanent conversation. Recipients can open the note without creating an account. See send a secret message without an account.
Secure file sharing
Use secure file sharing for documents, photos, and other attachments. Files are encrypted in your browser before upload and shared through a temporary link, rather than attached directly to an email or chat. Sending files requires a free sender account; recipients do not need an account.
The note’s open limit and the attachment access window are different controls. After reveal, files remain available for a limited time—one hour by default—so the recipient can preview or download them. This does not prevent them from keeping a downloaded copy.
Audio and voice messages
Record a voice message in PrivateNote or attach an audio file when speaking is easier than typing. Audio is encrypted before upload and decrypted in the recipient’s browser for playback. Sending recordings uses the same account requirements as other attachments.
When shouldn’t you use one?
A one-time link is the wrong tool when the job is storage, collaboration, or a record you are required to keep.
Poor fits
- Long-term password storage: use a password manager vault.
- Ongoing conversation: use a messenger both parties already trust, such as Signal.
- Organizational records that must be retained for audit or legal hold.
- Secrets that do not need to be transmitted at all—generate them in place, or don’t share them.
- Cryptocurrency seed phrases and other unrecoverable master secrets: a link can still leak if the full URL is copied. Read crypto seed phrases and one-time links before using this pattern there.
One-time links vs email, messaging and password managers
The useful comparison is purpose and persistence—not a ranking of which channel is “secure.”
| Method | Primary purpose | E2EE | Typical persistence | Suitable for temporary secret handoff? |
|---|---|---|---|---|
| Persistent correspondence | Transport encryption is common; end-to-end is not generally the default | Usually retained in multiple mailboxes, backups, and search | Poor fit for plaintext secrets | |
| Slack / Teams | Workplace conversation and search | Encrypted in transit and at rest on the platform; not end-to-end by default | Searchable, exportable workspace history | Poor fit for plaintext secrets; acceptable for sending a link |
| SMS / iMessage | Personal messaging | Varies widely by carrier and platform | Often backed up or cloud-synced | Poor fit for plaintext secrets |
| Private conversation | End-to-end for chats; backups may not be | Device and optional cloud backup copies | Better than email for conversation; still a poor place to park a password | |
| Signal | Private conversation | End-to-end | Disappearing messages are configurable | A reasonable alternative when both parties already use it |
| Password manager | Credential storage and sharing | Yes, by design | Built for long-term retention | Excellent for teams and standing access; often heavier than an ad-hoc handoff |
| PrivateNote | Temporary encrypted handoff | Client-side encryption; key in the URL fragment | Note open limit and expiry, with a separate access window for files and audio | Designed for this use case |
The link-preview problem
Many chat apps fetch an incoming URL to build a preview—title, description, thumbnail. If merely requesting the page counted as a read, that crawler would burn a one-time link before the recipient opened it.
PrivateNote does not treat a page load as a read. The public note URL returns a click-to-reveal gate. Metadata for that page can be fetched without returning plaintext. Ciphertext is retrieved only after a deliberate Reveal action. A Slack, Teams, or iMessage preview therefore does not receive the secret, and it does not consume the view limit.
That is a client and API design choice, not a list of blocked crawler user-agents. It still matters how you send the link: anyone who has the full URL, including the fragment, and who clicks Reveal, can read the note. For the recipient-facing warning, see why notes wait for click-to-reveal.
How to create a one-time secret link
Keep the steps short. The tool does the encryption; you choose the access rules.
- 1Open PrivateNoteUse the editor on the site—no account is required for a text note.
- 2Enter what you need to shareType a password, message, or API key. With a free account, attach files or record audio; use the secure file sharing page for a file-first transfer.
- 3Choose expiry and accessPrefer the shortest practical lifetime. Default is one view and a one-day unused expiry. Add a password or recipient verification when the sensitivity warrants it.
- 4Create the encrypted linkThe browser encrypts the note and attachments before uploading them. The decryption key stays in the link.
- 5Send the link to the intended recipientShare the link instead of pasting the message, sending the original files, or uploading the audio to the conversation.
When you are ready, create a one-time secret link.
Before sending a secret
A careful handoff is mostly operational. The cryptography cannot fix a wrong recipient.
- Confirm the recipient before you send the full URL.
- Use the shortest practical expiry.
- Add a password or recipient verification when the sensitivity warrants it.
- Send any extra authentication factor through a separate channel.
- Rotate temporary credentials after they have been used.
- Do not transmit secrets that do not need to move.
- Remember that the recipient can copy, screenshot, or photograph what they see.
Frequently asked questions
What is a one-time secret link?
A URL that delivers a secret for retrieval, then makes the server-side encrypted copy unavailable according to access and expiry rules—so the plaintext does not have to live in email or chat history.
How does a one-time link work?
The sender’s browser encrypts the content, the server stores ciphertext, and the decryption key stays in the URL fragment. The recipient reveals the note in their browser, which decrypts it locally.
Are one-time secret links secure?
They can be, when encryption is client-side, keys are strong, and access plus expiry are real. They do not protect compromised devices or a recipient who copies the secret after viewing it.
What happens after a one-time link is opened?
A successful reveal counts as an open. With the default one-open limit, the note cannot be revealed again. Files and audio remain accessible for a separate, limited window after reveal. Content already displayed or downloaded can remain on the recipient’s device; expiry does not erase their copies.
Can I send a password with a one-time link?
Yes. Put the password in the note, not in the chat message that carries the link. See how to share a password securely for split-channel tips.
Can I send a file with a one-time link?
Yes. Use secure file sharing to send documents, photos, or other files. Sending requires a free account; recipients do not need one. Files are encrypted before upload and have a limited access window after the note is revealed.
Can I share audio or a voice message?
Yes. Record audio in PrivateNote or attach an audio file. Like other attachments, it is encrypted in your browser before upload. Sending requires a free account; recipients can listen in their browser during the attachment access window without creating an account.
Is a one-time link safer than email?
Safer for the secret itself, because email keeps plaintext. The link can still travel over email; the difference is that the mailbox holds a URL, not the credential.
Can someone screenshot a one-time secret?
Yes. Recipients can copy text, capture their screen, save downloaded files, or record audio playback. A temporary link limits access to the server-side content; it cannot recall copies the recipient has already made.
What’s the difference between a one-time link and an expiring link?
One-time is about access: unavailable after the intended retrieval. Expiring is about time: unavailable after a deadline even if never opened. PrivateNote uses both.
Does the recipient need an account?
No. Anyone with the full link can open an unprotected note. A password or recipient verification applies only if the sender enabled it.
Where PrivateNote fits
PrivateNote is for temporary handoff: a password, a private message, a document, or an audio recording. Encrypt in your browser, share a link, and limit how long the content stays accessible. For secure file sharing, remember that the attachment access window is separate from the note’s open limit, and recipients can keep copies they download.
Match the lifetime of the secret to the lifetime of the medium that carries it.
Create a one-time secret link
Share a message, password, file, or audio recording through a temporary link, with encryption in your browser.
Create a one-time secret link
