Start with the narrow claim: after the read count is reached or the link expires, the ciphertext is gone from the server, so another fetch by the same id cannot return the original bytes. That claim does not support “the recipient took no screenshot,” “nobody else in the channel opened it,” or “chat backups hold no full link.” The check is two opens plus Network—not treating Burned as an audit of the other device.
Answer the search intent in one sentence
Burn-after-read can support one conclusion: the host no longer holds the ciphertext. It cannot support the claim that the recipient’s screen, clipboard, or chat history was wiped. After the first successful ciphertext fetch, opening the same link again shows Burned or Expired. Under HTTP 410 Gone, the target resource is no longer available at the origin, and that condition is usually permanent. That answers “will the server still hand it over.” It does not answer “did they keep a copy.”
This note is for developers, ops, and anyone who wants to separate “the link is dead” from “they kept nothing” before they send a one-time password, an API key, or a recovery code. It does not replace the Burn-Link how-to, and it does not repeat how to mint a URL. What you should take away is which layer burned, what a failed refresh can prove, why screenshots sit outside that layer, and how two opens plus Network let you check the host side on this device.
Burned is not the same as “they kept no copy”
Everyday talk folds three different facts into “this message vanishes after you read it.” First: the server no longer stores ciphertext. The record for that id is gone, and a later request only gets Burned or Expired. Second: this tab no longer shows plaintext. Closing the page, clicking Clear from this page, or a script emptying the box on leave can do that. Third: the recipient’s device holds no copy—no screenshot, no paste, no forward of the full link, no plaintext pasted back into chat.
Burn-after-read can enforce the first fact. It can at most clear the display in this tab for the second. It has no force over the third. The read page can say it does not stop copying or screenshots. That is a boundary, not a missing feature: a web page cannot stop another phone from photographing the screen, and it cannot reach into the system clipboard or a chat app’s local store after someone clicked Copy plaintext.
So “I refreshed and it will not open” supports a narrow conclusion: this fetch by id did not return ciphertext. It does not support “only that colleague saw it,” “they took no screenshot,” or “this string will never show up in a ticket search.” Those later sentences need a different observation: whether plaintext or the full URL left this tab—not whether your second open failed.
Which layer the server actually burns
A zero-knowledge burn link splits location from decryption. The shape is s.html?id={id}#{key}: the query holds only the id; the key sits after the hash. RFC 9110 says the request’s target URI excludes the fragment. When the browser asks the server for the document, it drops # and everything after it. By design the server sees the id, not the key, and not the plaintext.
On create, this tab uses Web Crypto for AES-256-GCM: a random 32-byte key, a 12-byte IV, and plaintext packed into ciphertext on this device before POST /secrets. The outbound fields are ciphertext, expiry, and the read count. The key appears only in the share URL built afterward. One item is capped at 32 KB. Expiry can be 1 hour, 24 hours, 7 days, or burn after a read only. The read count is 1–10, default 1. Create and read are ready to use. There is no account, and no login identity for “who opened it.”
On read, after the server hands over ciphertext and the set count is reached, it deletes that ciphertext. When you open the link again, you see Burned or Expired. That proves the host no longer holds those ciphertext bytes. It does not prove the key never sat in chat history, that plaintext never hit the other screen, or that a third person never clicked Open and view on the same full URL.
Anyone who has the full URL still holds the key. Pasting https://…/s.html?id=…#… into a channel hands over both the id and the key. Even after the server burns the ciphertext, that delete cannot rewind a person who already opened it and kept the plaintext. If reads remain, a later click can still fetch ciphertext. Burning ciphertext addresses long-term storage at the host. It does not address “everyone who saw the whole string.”
What a failed refresh can prove—and what it cannot
A second open that fails is not one status. Split three prompts. Burned: the ciphertext is gone, either because the read count was used or because the id was never valid. Expired: the TTL chosen at create time ran out, so the server deleted the record even if nobody read it. Missing fragment key: the id may still exist, but this device cannot decrypt. Slack, Teams, WhatsApp, and some mail clients truncate everything after #. The recipient then sees Missing fragment key, which is not the same event as “someone else already read it.”
410 Gone means the target resource is no longer available at the origin, and that condition is likely permanent. The read page splits 410 into Burned and Expired: if the response marks expired, that is TTL; otherwise it is treated as burned. A 404 is also shown as Burned, because the result for the recipient is the same—ciphertext cannot be fetched again. A network error is not a burn: if the drop happens after Open and view, and create allowed only one read, the ciphertext may already have been taken even though this tab never decrypted it.
So “it will not open on my refresh” supports this: a fetch by this id no longer returns ciphertext. It does not support: the opener was the named colleague; they did not copy; they did not screenshot; a preview bot or a security scanner did not spend a read first. With no accounts, there is no named read receipt. The count lives on the server. It is not an audit of the recipient’s device.
Do not test with a real password, API key, or unredacted connection string. Write a sentence that exists only for this check. You are comparing the status call, the ciphertext fetch, and the second-open prompt—not exposing a live credential again.
Why screenshots, copies, and chat history sit outside this layer
Once plaintext is painted on a screen, the question leaves “does the server still have ciphertext” and becomes “what happened on the other endpoint.” A system screenshot, a screen recording, or a second phone pointed at the display never sends a request to the host. The read page cannot intercept those actions, and it cannot notify you afterward. That is not an unfinished product checkbox. Ordinary web pages are not given a switch that forbids the other person from recording their own screen.
Copy sits outside the same fence. The read page can offer Copy plaintext, and it can empty the box when you leave. What it empties is this DOM node—not the system clipboard, and not a chat draft. macOS and some input methods keep clipboard history. Cleared from this page only means this tab no longer shows the sentence. It does not mean the sentence never entered the clipboard.
Chat history is a separate store. If the full link appeared in a channel, group history, search, multi-device sync, and a later export can all show the key after the hash again. Even after the server burns the ciphertext, the URL remains evidence that the link once worked, and it is enough to make someone who does not know the count is spent keep clicking and decide “the link is broken.” The HTTP layer can still be clean—Referer must not carry a fragment—but that protection is already gone for anyone who can open the chat log.
Tickets, mail, and browser history follow the same split. A # fragment that appeared in the address bar usually lands in local history; a signed-in browser may sync that row to other devices. Closing the tab is not clearing history. Burn-after-read shortens how long the server keeps a blob, and it limits how often the same ciphertext can be fetched. It is not digital rights management, and it is not a forensics report.
Why a status check does not consume a read
If the first load of the landing page fetched ciphertext, a chat preview, a mail security gateway, or an enterprise scanner could spend the only read before the recipient clicked. They would then see Burned, even though the key was never given to the preview host. What burned is the read count, not the secrecy of the fragment. An earlier note covers why the hash stays out of HTTP by default. This one stays on the count: a preview request and a real ciphertext fetch have to be separate, or Burned cannot even support “the recipient saw it.”
FastPwd’s read page splits those steps. Opening the page requests /secrets/{id}/status only: is the ciphertext still there? It does not take the blob. After the recipient clicks Open and view, the tab GET /secrets/{id} and decrypts locally with the key after the hash. If the # key is missing, the page will not fetch ciphertext, so it does not waste remaining reads. Neither the create page nor the read page needs an account.
Preview bots usually pull the landing page and do not click the button. That lowers the chance of “preview equals burn.” It does not prove every scanner stops there. In Network you should see a status call first, then a ciphertext fetch; a load with no click should not show a successful take of the blob. The count is still a server-side counter. It is not part of the fragment.
| What you see | What it can support | What it cannot support |
|---|---|---|
| A second open shows Burned | A fetch by this id no longer returns ciphertext | The recipient took no screenshot and made no copy |
| The page shows Expired | TTL ended and the server deleted the record | Someone successfully read it |
| The page shows Missing fragment key | The address has no key after # |
The ciphertext has already been taken |
| The page loaded; the button was not clicked | A status check should not consume a read | Every preview bot will refuse to fetch ciphertext |
| Network shows ciphertext only on POST | This create did not send the original sentence as a business field | After the full link is pasted into chat, only you can still see it |
| Plaintext was cleared from this page | This tab no longer shows that sentence | The clipboard and screenshots are empty too |
Check it now: two opens, status, and Network
A slogan is not evidence. Prepare a disposable canary such as canary-fp-20260905-burn-vs-shot. Do not reuse a live password. Leave the read count at the default of 1, and keep expiry at 24 hours.
- Put the canary on the create page and generate a link. Open Network in DevTools and turn on Preserve log. Search the canary and the key after the hash separately: the body of
POST /secretsshould hold ciphertext, expiry, and the read count—not the original sentence or the key. - Open the read page with the same full link. Do not click Open and view yet. Network should show
/secrets/{id}/statusand should not show a successfulGET /secrets/{id}that took the blob. The page should wait for confirmation. - Click Open and view. Only then should ciphertext be fetched by id and decrypted on this device with AES-256-GCM. The success note will say the server has deleted this ciphertext—or, if you raised the count above 1, that deletion waits until that count is reached.
- Refresh the read page, or open the same link in a fresh browser context. With one read, you should see Burned. Search Network again: the ciphertext fetch should return 410 or a response treated as burned. The canary should not reappear as plaintext in any request body.
Those four steps prove one change: between two opens you control, ciphertext on the server went from present to absent. They do not prove that, if this had been a real password for a colleague, they took no screenshot. “Will they keep a copy” belongs in the handoff note—do not screenshot, do not paste plaintext back into the channel, rotate the secret after use—not in the hope that Burned will audit their endpoint for you.
Do not send the full link and the ciphertext on the same path. Put a .lock file on a drive or in mail, and send the passphrase through Burn-Link. Do not drop the full Burn-Link URL into that folder’s notes. If the key and the box travel in one message, burning the ciphertext will not help anyone who already saw the whole string.
Three ways people read Burned too far
First, they treat Expired as proof someone read it. Create used 1 hour; the colleague clicked the next day; the page says Expired. The server deleted the ciphertext, but the reason is TTL, not a spent read count. Unread content that expired cannot be recovered. That is not the same as “it was already opened.”
Second, they treat a missing fragment as already burned. Slack, Teams, and some mail clients cut everything after #. The recipient opens s.html?id=… with no key. The read page will not fetch ciphertext without a key. If you later open the full link, the content may still be there. Ask them to resend the string that includes the hash. Do not decide “someone got there first.”
Third, they treat Clear from this page as a global wipe. The read page can empty the box on leave, and it can use history.replaceState to drop the fragment from the address bar. That only changes what this tab shows and whether a later refresh still carries the key. System screenshots, clipboard history, chat backups, and synced browser history are outside that clear.
FAQ
If they refresh and see Burned, does that mean they kept nothing?
No. It only means the ciphertext is gone from the server, so another fetch by id cannot return the original bytes. A screenshot, a copy, a screen recording, a chat backup, or forwarding the full link never goes through that delete. Burned is not proof that the recipient’s device is clean.
Can a chat-app link preview burn the secret first?
A preview usually loads the landing page only. The read page first asks whether the ciphertext is still there and does not take it; Open and view is what fetches ciphertext by id. Most preview bots will not click that button for you, but you cannot assume every scanner stops at the landing page. The read count is a server-side counter. The check: on a load with no click, Network should not show a successful ciphertext take.
Can burn-after-read prove who opened the link?
No. Create and read need no account, and the server does not tag a reader by login identity. What you can check is whether the id still has ciphertext after a fetch. You cannot reverse Burned into a name, and you cannot write it up as a read receipt.
Do I need to register to create or read? Is plaintext uploaded?
No. This tab encrypts with AES-256-GCM, then uploads ciphertext. The key sits in the # fragment. Search Network with a canary: the body should hold ciphertext, not the original sentence or the key after the hash. For more than 32 KB, or for a whole file, use the File Encryption Box on this device. Do not treat a burn link as a drive.
Run the same canary on a ready-to-use tool
If you want a page that writes the compute boundary in the open, open FastPwd Burn-Link. No account is required. Paste the canary above, leave the read count at 1, generate the link, and finish the two opens from the check section. Watch Network at the same time: you should see the ciphertext POST on create, status on the read page, the fetch after the click, and a burned response on the second open. You should not see the original sentence or the key after the hash as a business field.
Use this path only when a password must reach a colleague. You can generate the random password first on the password generator, locally, length 6–128, default 16; shorter than 8 is flagged as weaker. Generation is not uploaded. A whole contract, an ID scan, or anything over 32 KB belongs in the File Encryption Box, using the same AES-256-GCM into .lock / .enc, one file up to 5 GB. Send the passphrase on a burn link by itself. Do not write it into the drive’s notes.
Before the next send, keep three facts. First, Burned proves the ciphertext is gone from the server—not that the other person took no screenshot. Second, loading the landing page should not consume a read; Open and view is what fetches ciphertext. Third, after the full link is pasted into chat, the key after the hash is visible to anyone who can see that message. Only an observation you can repeat is worth writing into your own handoff note.
Further reading
Why the part after the hash stays out of HTTP by default, and which layer dies when you paste the full link, is in Why a URL hash can hold a key, and when that protection fails. “Local encryption, nothing uploaded” is not evidence until you search Network with a canary: How to check if browser encryption never uploaded plaintext. If you still need to mask ID numbers in a ticket before they leave this machine, see Before you paste tickets and logs into AI, check which fields leave this machine.