--- title: "How One-Time Secret Links Work | LinkPilot Blog" description: "A clear, developer-friendly explanation of how one-time secret links work — from creation to atomic burn-after-read." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://uselinkpilot.com/#software", "name": "LinkPilot", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "url": "https://uselinkpilot.com", "offers": [ { "@type": "Offer", "name": "Free", "price": "0", "priceCurrency": "USD", "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Pro", "price": "29", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "29", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Agency", "price": "299", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "299", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Enterprise", "priceSpecification": { "@type": "PriceSpecification", "priceCurrency": "USD" }, "url": "https://uselinkpilot.com/pricing" } ] }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://uselinkpilot.com/#organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "parentOrganization": { "@type": "Organization", "@id": "https://tetracorehq.com/#organization", "name": "TetraCore", "url": "https://tetracorehq.com/" }, "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 }, "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "sameAs": [ "https://x.com/uselinkpilot", "https://www.linkedin.com/company/uselinkpilot", "https://facebook.com/uselinkpilot" ] }, { "@context": "https://schema.org", "@type": "WebSite", "name": "LinkPilot", "url": "https://uselinkpilot.com", "potentialAction": { "@type": "SearchAction", "target": "https://uselinkpilot.com/blog?q={search_term_string}", "query-input": "required name=search_term_string" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uselinkpilot.com" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uselinkpilot.com/blog" }, { "@type": "ListItem", "position": 3, "name": "How One-Time Secret Links Work", "item": "https://uselinkpilot.com/blog/how-one-time-secret-links-work" } ] }, { "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://uselinkpilot.com/blog/how-one-time-secret-links-work#article", "headline": "How One-Time Secret Links Work", "description": "A clear, developer-friendly explanation of how one-time secret links work — from creation to atomic burn-after-read.", "datePublished": "2026-05-26", "dateModified": "2026-07-14", "image": "https://uselinkpilot.com/logo-512.png", "author": { "@type": "Person", "name": "W. Miller", "worksFor": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com" } }, "publisher": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://uselinkpilot.com/blog/how-one-time-secret-links-work" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What happens if two people open the link at the same time?", "acceptedAnswer": { "@type": "Answer", "text": "A correctly implemented one-time link performs the read and the mark-consumed in a single atomic database operation, so exactly one viewer wins. The other sees a 'burned' status. Without that atomicity, both can read the secret — a classic TOCTOU bug." } }, { "@type": "Question", "name": "Does a link preview burn the secret?", "acceptedAnswer": { "@type": "Answer", "text": "It shouldn't. Servers should only burn on an explicit reveal action (POST), not on the metadata fetch (GET) that chat and email clients use to render previews. LinkPilot's GET endpoint returns only status and whether a passphrase is required." } }, { "@type": "Question", "name": "Why do burned links return HTTP 410 instead of 404?", "acceptedAnswer": { "@type": "Answer", "text": "410 Gone means the resource existed and is intentionally, permanently unavailable — which is exactly the semantics of a burned secret. It tells clients and caches not to expect the content to return, and it's honest: the link was real, and it's spent." } }, { "@type": "Question", "name": "Can I recover a burned secret?", "acceptedAnswer": { "@type": "Answer", "text": "No — that's the point. In LinkPilot the stored payload is overwritten the moment the secret burns, expires, or is revoked, so there is nothing to restore. If you need recoverability, use a password manager and share a vault item instead." } }, { "@type": "Question", "name": "Is it safe to send a one-time link over email?", "acceptedAnswer": { "@type": "Answer", "text": "Reasonably, if the link expires and carries a passphrase sent through a different channel. Email is scanned, forwarded, and retained, so assume the URL itself may be seen — the passphrase and short expiry are what keep a seen URL from becoming a leaked secret." } } ] } ] --- [![LinkPilot](/link_pilot_icon.webp)LinkPilot ](/) [Features](/features)[Tools](/tools)[Blog](/blog)[Pricing](/pricing)[FAQ](/#faq) Toggle theme [Sign In](/login)[Start free](/signup) 1. [Home](/) 2. [Blog](/blog) 3. [Security](/blog/category/security) 4. How One-Time Secret Links Work [Security](/blog/category/security) # How One-Time Secret Links Work A clear, developer-friendly explanation of how one-time secret links work — from creation to atomic burn-after-read. By W. Miller · May 26, 2026 · 7 min read A one-time secret link is a URL that reveals its contents exactly once and then becomes permanently inert. The mechanism is simple, but the edge cases are where it gets interesting — and where sloppy implementations quietly leak. ## The basic flow 1. Sender creates a secret. The server stores the payload (encrypted at rest, ideally in storage isolated from everything else) and returns a URL with a random, hard-to-guess [slug](/glossary#slug "Glossary: slug"). 2. Sender shares the URL through any channel — email, chat, SMS. 3. Recipient opens the URL. The server checks status, atomically marks the secret as consumed, and returns the payload in the same operation. 4. Any subsequent visit gets a "burned" status page instead of content. The critical step is step 3. If the read and the status update happen as two separate queries — `SELECT` to check, then `UPDATE` to mark — two concurrent viewers can both pass the check before either one writes. Both get the payload. That's a classic TOCTOU (time-of-check to time-of-use) bug, and it converts your "exactly once" guarantee into "usually once." ## Atomicity in practice The fix is to collapse the check, the mark, and the read into one database operation. In Postgres that looks like: ```sql UPDATE secrets SET burned_at = now() WHERE slug = $1 AND burned_at IS NULL AND expires_at > now() RETURNING payload; ``` The row-level lock the `UPDATE` takes means concurrent callers serialize: the first one matches the `WHERE` clause, flips `burned_at`, and gets the payload back via `RETURNING`. Every later caller finds `burned_at` already set, matches zero rows, and gets the burned status. There is no window between "check" and "consume" because they are the same statement. LinkPilot records views atomically through a database function for exactly this reason — concurrent reveal attempts cannot leak the secret twice. If you're evaluating a tool, this is a fair question to ask the vendor directly: _is the burn atomic with the read?_ ## What "burned" should look like: HTTP 410 Once consumed, the link should fail loudly and permanently. LinkPilot does two things on burn: - The stored payload is **overwritten** with `[REDACTED]` in the same write that flips the status — so even a later database compromise can't recover a spent secret. - Subsequent reveal attempts return **[HTTP](/glossary#http "Glossary: http") 410 Gone** with a clear "already viewed and destroyed" page. 410 is the right status code: it means the resource existed and is intentionally, permanently unavailable — as opposed to 404, which says "never heard of it." The distinction matters for humans too: a recipient who sees "this secret was already viewed" knows to tell the sender, who can check the [audit trail](/glossary#link-history "Glossary: audit trail") and rotate if the viewer wasn't them. ## Hard-to-guess slugs, and why they aren't enough The slug is the only thing standing between the public internet and an unread secret, so it has to carry real entropy. A slug drawn from a cryptographically secure random source with, say, 22 characters of base62 carries roughly 128 bits — enumeration is not a realistic attack at any request rate a server would survive. But slug entropy only defends against _guessing_. It does nothing about the URL being _observed_: browser history, proxy logs, forwarded emails, screen shares, clipboard managers. That's why serious implementations layer on: - **Expiry**, so an observed URL goes dead on schedule. - **A passphrase**, so an observed URL alone isn't sufficient. - **[Burn-after-read](/glossary#burn-after-read "Glossary: burn-after-read")**, so an observed URL is worthless after the legitimate read. ## Link previews and bots Chat clients (Slack, Teams, iMessage) and email security scanners unfurl URLs by fetching them with a `GET` request the moment a message is delivered. If your reveal [endpoint](/glossary#endpoint "Glossary: endpoint") burns on `GET`, the unfurler destroys the secret before the human ever sees it — the most common real-world failure of naive burn-after-read tools. The defenses, as LinkPilot implements them: - **Separate metadata and reveal actions.** A `GET` on the reveal endpoint returns only status and whether a passphrase is required. A view is recorded only on an explicit `POST` — the action a human takes when they click the reveal button. - **Passphrase gate.** When a passphrase is set, no payload is returned to anyone — bot or human — without the correct hash. - **`Cache-Control: no-store`** on every reveal response, so intermediaries never cache secret contents. [LinkPilot's Security Architecture page](/security-architecture) documents this handling end to end. ## The lifecycle, state by state State Triggered by What a visitor sees Payload recoverable? Active Creation Reveal page (passphrase prompt if set) Yes — one reveal available Burned View-count limit reached "Already viewed and destroyed" — HTTP 410 No — payload overwritten Expired Expiry deadline passes Expired status page No — redacted on next access Revoked Sender kills it from the dashboard Refuses to reveal — HTTP 410 No — immediate and permanent Every transition lands in an audit timeline. LinkPilot's event types are `created`, `viewed`, `failed_passphrase`, `burned`, `expired`, and `revoked`, each with a timestamp and a hashed IP (SHA-256 with a daily-rotating salt — the raw IP is never stored). That trail is what turns "I think they got it" into "viewed at 10:05 from the expected country, one view, then burned." ## Common extensions - **Passphrase gate** — require an out-of-band passphrase before the reveal, so a leaked URL alone is not a leaked secret. Rate-limit attempts; LinkPilot allows 5 per IP per minute per secret and logs every failure. - **Time-based expiry** — the secret dies after a set window (5 minutes to 30 days in LinkPilot) even if never read. Covers the forgotten-in-inbox case that burn-after-read can't. - **Manual revoke** — the sender can kill an unread secret from the [dashboard](/glossary#dashboard "Glossary: dashboard") the moment something feels off. Cheap insurance for "sent it to the wrong Alex." ## Edge cases that separate good implementations ### The wrong person opens it first Burn-after-read doesn't stop the wrong viewer — it makes the misdelivery _visible_. The intended recipient hits a burned page, the audit trail shows one view you didn't expect, and you rotate the credential. Painful, but bounded: exactly one exposure, detected quickly. Compare that with a pasted-in-chat secret, where you'd never know. ### The screenshot problem One-time means one _reveal_, not one _copy_. The recipient can screenshot, copy, or retype the secret — nothing about the link prevents that, and vendors who imply otherwise are selling fiction. The honest framing: burn-after-read controls the delivery channel, not the recipient. Trust in the recipient is an input, not an output. ### Browser prefetch and speculative loading Some browsers and apps prefetch likely-clicked URLs. Because a well-built tool only burns on an explicit `POST`, prefetch behaves exactly like an unfurler: it can fetch the page shell, never the payload. ## When not to use a one-time link - **The value will be needed again.** Recoverability is the whole design goal of a password manager and the anti-goal of a one-time link. Use a vault item. - **Multiple recipients need it.** One link, one read. Fan-out means either creating one link per person (fine, auditable) or admitting you need shared access control instead. - **A machine is the consumer.** Services and CI should read from a secrets manager, not click links. If you want to watch the mechanism in action, [create a Secret Link](/secret-sharing) — the lifecycle is logged, so you can see the created, viewed, and burned events fire in real time. ## Related reading - [How to send a password securely](/blog/how-to-send-a-password-securely) - [Best OneTimeSecret alternatives](/blog/best-onetimesecret-alternatives) - [OneTimeSecret vs Privnote vs Password Pusher](/blog/onetimesecret-vs-privnote-vs-password-pusher) - [Expiring links: why short windows matter](/blog/expiring-links-security) ## Frequently asked questions ### What happens if two people open the link at the same time? ### Does a link preview burn the secret? ### Why do burned links return HTTP 410 instead of 404? ### Can I recover a burned secret? ### Is it safe to send a one-time link over email? ## Run smarter links with LinkPilot Tracking, UTMs, QR codes, AI insights, and white-label reporting — in one workspace. Free to start. [Create your free account](/signup) ## Read next [ Security ### OneTimeSecret vs Privnote vs Password Pusher: Which Should You Use? A three-way comparison of the most popular secret-sharing tools — encryption, expiry, revocation, self-hosting, and where each one genuinely wins. ](/blog/onetimesecret-vs-privnote-vs-password-pusher)[ Security ### Is Privnote Safe? An Honest Security Assessment (2026) Privnote's core mechanism works, but clone-site phishing, closed source code, and zero auditability are real risks. Here's a fair assessment and safer setups. ](/blog/is-privnote-safe)[ Security ### How to Send a Password Securely (Without Leaving It in Chat Forever) The safest way to send a password is a one-time encrypted link that self-destructs after viewing. Here's every method ranked, with the trade-offs spelled out. ](/blog/how-to-send-a-password-securely) On this page - [The basic flow](#the-basic-flow) - [Atomicity in practice](#atomicity-in-practice) - [What "burned" should look like: HTTP 410](#what-burned-should-look-like-http-410) - [Hard-to-guess slugs, and why they aren't enough](#hard-to-guess-slugs-and-why-they-arent-enough) - [Link previews and bots](#link-previews-and-bots) - [The lifecycle, state by state](#the-lifecycle-state-by-state) - [Common extensions](#common-extensions) - [Edge cases that separate good implementations](#edge-cases-that-separate-good-implementations) - [The wrong person opens it first](#the-wrong-person-opens-it-first) - [The screenshot problem](#the-screenshot-problem) - [Browser prefetch and speculative loading](#browser-prefetch-and-speculative-loading) - [When not to use a one-time link](#when-not-to-use-a-one-time-link) - [Related reading](#related-reading) ![LinkPilot](/assets/link_pilot_icon-Bslvq5xV.webp)LinkPilot [About](/about)[Features](/features)[Pricing](/pricing)[For Agencies](/url-shortener-for-agencies)[Tools](/tools)[Blog](/blog)[Glossary](/glossary)[Compare](/compare)[Privacy](/privacy)[Security](/security-architecture)[Transparency](/transparency)[Terms](/terms)[GDPR](/gdpr) [](https://x.com/uselinkpilot)[](https://www.linkedin.com/company/uselinkpilot)[](https://facebook.com/uselinkpilot) © 2026 TetraCore. All rights reserved. · LinkPilot is [a TetraCore product](https://tetracorehq.com/)