How one-time secret links work
A one-time secret link is designed to release an encrypted message once and make the stored payload unavailable afterward. That is useful for delivery, but it is not the same as guaranteeing that only the intended person saw the message.
By SecretLink Editorial Team · Published August 23, 2026 · Updated August 23, 2026
The lifecycle of a one-time link
When a sender creates a one-time SecretLink, the message is encrypted in the sender's browser. The server receives encrypted ciphertext and delivery settings, while the random decryption key stays in the URL fragment after the # symbol. Browsers do not include that fragment in ordinary HTTP requests.
On the first valid retrieval, SecretLink atomically marks the message as consumed and returns the encrypted payload. The recipient's browser uses the key from the URL to decrypt it locally. Later retrieval attempts cannot obtain the encrypted payload from SecretLink.
Why atomic first access matters
A weak one-time system might check whether a message was viewed and mark it afterward. Two nearly simultaneous requests could both pass the check. Atomic consumption combines the decision and update so only one request can claim the payload.
This protects against repeated retrieval from the service, including accidental reopening in another tab. It does not identify who made the successful request. The first viewer could be the intended recipient, an email security scanner that follows links, or someone who obtained the URL.
When one-time links are a good fit
Use one-time delivery for information that needs one immediate handoff: a temporary password, recovery code, short-lived access instruction, alarm code, or private note. Before sending, tell the recipient to open the link only when they are ready to use or store the information.
For information that must be consulted repeatedly, a one-time link may create avoidable failure. A password manager, access-management system, encrypted file workspace, or individual user account is usually better for ongoing access.
- Good fit: a recipient is expecting a single, immediate handoff.
- Good fit: the underlying code or credential is temporary or revocable.
- Poor fit: several people need the same information.
- Poor fit: the recipient must return to the information later.
- Poor fit: opening the link itself could trigger automated scanning.
Example: delivering a recovery code
Imagine an administrator must provide one backup code to a remote employee. The administrator verifies the employee on a known video call, creates a one-time link containing only the code, and sends it through the company's direct-message system while the call is active.
The employee opens the link, uses the code immediately, and confirms success. The administrator then invalidates any remaining recovery codes and creates a fresh set. The one-time link reduced repeat retrieval, while code rotation removed the value of any copy made during delivery.
Important limitations and failure cases
A one-time link is a delivery control, not digital rights management. Once plaintext appears, the viewer can copy it, save it, photograph it, or enter it elsewhere. Device malware and malicious browser extensions may also read displayed content.
Some messaging and email systems automatically inspect links. If a scanner reaches a one-time URL before the recipient, it may consume the message. Password protection, recipient coordination, and a channel that does not prefetch links can reduce that risk, but behavior varies by system.
- First access proves only which request arrived first, not the viewer's identity.
- The complete URL is sensitive because its fragment contains decryption material.
- One-time retrieval cannot recall plaintext already displayed or copied.
- A consumed message may indicate successful delivery, automated scanning, or interception.
Use one-time viewing as one layer
Combine one-time viewing with a short expiration, a separately delivered access password, recipient verification, and revocable credentials. Each measure addresses a different failure mode.
If a link is unexpectedly consumed, assume the secret may have been exposed. Do not simply send the same credential again. Verify the recipient, rotate or invalidate the original secret, and create a new handoff.
Related guidance
When an encrypted delivery link is appropriate, create a free SecretLink account.