What Is a One-Time Secret Link? How Secure Sharing Works
Temporary encrypted handoff—not a vault, and not a conversation
A one-time secret link delivers a password, credential, or private message without leaving plaintext in email or chat history. Here is how the model works, when to use it, and how PrivateNote implements it.
Kluczowe wnioski
- 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.
A one-time secret link is a URL used to deliver sensitive information without leaving the plaintext permanently in email or chat history. The recipient opens the link, reveals the secret in the browser, and the encrypted copy on the server then becomes unavailable according to the link’s access and expiry rules.
It is useful for passwords, API keys, recovery codes, temporary credentials, and private messages that need to reach someone once and do not need a permanent conversation history.
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.
Need to send one now? Create an encrypted one-time link with PrivateNote
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 a client-side design like PrivateNote’s, the secret is encrypted in the sender’s browser before upload. The server stores ciphertext. The recipient’s browser decrypts it locally. Note text uses AES-256-GCM via the Web Crypto API.
Step 1: Your browser
Browser-generated key and encryption
You write the secret locally. The browser generates cryptographic material and encrypts the plaintext before any network request leaves the device.
Step 2: The server
Ciphertext upload
Only the encrypted payload is uploaded. The server stores ciphertext it cannot read, because it does not receive the plaintext or the fragment key.
Step 3: The URL
Key stays in the link
The decryption key is placed in the URL fragment—the part after #. The public path identifies the note; the fragment stays in the browser under normal URL handling.
Step 4: The recipient
Reveal, decrypt, then apply access rules
Opening the page is not enough. The recipient clicks to reveal, which fetches ciphertext. The browser decrypts locally. After a successful reveal, PrivateNote applies the view limit—one view by default—and deletes the ciphertext when that limit is reached. Unused links also expire on a timer.
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. After the intended retrieval—on PrivateNote, a successful reveal that reaches the view limit—the encrypted payload is gone from the server.
- 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. That is temporary handoff: retrieve it, or wait, and the server-side copy goes away.
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.
Sensitive files
Files need extra care: size, download, preview, and a separate access window after the note is opened. On PrivateNote, sending a file requires a sender account; recipients still do not. Attached files remain fetchable for a limited window after reveal—one hour by default—not indefinitely. Use secure file transfer when the payload is a document rather than a short secret.
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 | View limit plus time expiry; ciphertext deleted when those conditions are met | 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 shareA password, message, API key, or, with an account, a file.
- 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 first, then uploads ciphertext.
- 5Send the link to the intended recipientDo not paste the plaintext alongside it.
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?
On PrivateNote, a successful reveal counts as a view. With the default one-view limit, the server then deletes the ciphertext. The content can remain visible in the already-open browser. Unused links also expire on a timer.
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, through PrivateNote’s secure file transfer. Sending requires a free account; opening does not. After reveal, attachments follow a separate access window—one hour by default.
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. Once content is on a screen, it can be copied, photographed, or captured. A one-time link limits the original server copy; it is not DRM.
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 a handoff tool. It is not a long-term password vault, a team wiki, or a compliance archive. Encrypt in the browser, share a temporary link, and let the server-side copy expire when the job is done.
Match the lifetime of the secret to the lifetime of the medium that carries it.
Create a one-time secret link
Encrypt a message, password, or file in your browser and share it through a temporary link.
Create a secure link