After you close a burn-after-reading tab, why the key after # still comes back from Recently closed tabs

Once you open https://…/s.html?id=…#…, the address bar holds two pieces at once: the ciphertext id after the question mark, and the decryption key after #. Closing that tab is easy to read as “the key is no longer on this computer.” The browser is doing the opposite job. To support Back, Forward, crash recovery, and Recently closed tabs, it has to keep the full URL from that navigation. Chromium calls this per-tab record session history: a navigation entry stores the URL at that moment, scroll position, and uncommitted form data. After a tab is closed or the browser restarts, those entries are serialized so the tab can come back as it was. See Chromium’s Session History document.

Firefox names the same family of features Session Restore. It tracks windows, tabs, and recently closed tabs, and writes each tab’s history, scroll position, and form data to disk so startup or “Undo Close” can read them back. See Firefox Source Docs: Session Restore. Microsoft Edge is built on Chromium, so restoring a closed tab uses the same session-history path — not a separate rule that “keeps the title and drops the fragment.”

That layer is not the HTTP request. IETF RFC 3986 §3.5 defines the fragment as client-side identification. It is not used by the server when processing the URI. UsePwd access logs therefore do not contain the key after #. That boundary is already unpacked in Why URL hash fragments never reach the server. This article fills the next layer: a fragment that never enters the request can still enter your own browser record. Closing the tab ends this paint. It does not automatically erase the full URL sitting in session history.

In Chrome or Edge, press Ctrl+Shift+T, or open History → Recently closed. The browser takes that session record and opens the URL stored inside it. Chrome’s own shortcut list calls this “Reopen previously closed tabs in the order they were closed”; see Chrome keyboard shortcuts. Firefox’s Recently closed tabs list does the same from Session Store: it treats the URL of the active history item as the restore target. The fragment is part of the URL, not decoration next to the page title. Restore has no extra step that peels it off.

Long-term history and session history are also not the same store. When Chromium writes a URL into the history database, it strips username and password. The conversion does not clear the fragment. The function is Chromium GurlToDatabaseUrl. So a burn-after-reading address that still shows # in chrome://history does not contradict “the request had no fragment”: the history database stores the full string you visited; the request line is still only s.html?id={id}.

Right-click Duplicate tab is a shorter path. Chromium documents that duplicating a tab — or running Back, Forward, or Reload in a new tab — clones the navigation entries directly, instead of writing them to a file and reading them back. The cloned tab’s address bar is usually the same string as before, including # and the key. On a shared computer that is faster than digging through History: the person next to you does not need to know how to search history. Duplicating the tab is enough.

When you bookmark the read page, the browser saves the string that is in the address bar. The star button does not first ask “is the text after # a key?” and then store only the path. Later, any device that syncs bookmarks can open that entry and show the full link in the address bar again. Apple’s iCloud guide says that after you turn on iCloud for Safari, bookmarks and open tabs are stored in iCloud and stay up to date on iPhone, iPad, and Mac; bookmarks also sync to PCs that run iCloud for Windows. See Keep Safari in sync across your devices with iCloud.

Chrome lists “History and tabs” as a sync item you can turn on. Once it is on, open tabs appear under History → Tabs from other devices. The help page is Get your bookmarks, passwords, and more on all your devices. Chrome’s Send tab to your devices path writes the full GURL spec() into the sync record. An ordinary # fragment is serialized with the rest of the URL; it is not stripped first. The implementation is Chromium SendTabToSelfEntry.

Do not treat the system share sheet as the same thing as a bookmark. On iPad Safari, sharing a URL that includes a fragment into Mail sometimes leaves only the part before #. Selecting the whole address bar and copying usually keeps the fragment. That difference is the point: do not decide “the key is gone” because you tapped Share. Decide from the characters that actually appear in the recipient’s — or the other device’s — address bar. Chat preview fetching that stops at the title is a different article. Once the full link is in a bookmark or a sync record, it is no longer a preview bot.

UsePwd Burn-Link puts the key after # in s.html?id={id}#{key}. Create and read both open immediately — neither side registers. The current tab encrypts or decrypts with Web Crypto and AES-256-GCM. Plaintext is at most 32 KB. The only uploaded fields are ciphertext, a TTL, and a read count. Expiry can be 1 hour, 24 hours, 7 days, or “burn after read only.” Reads are 1–10, default 1. The server only stores ciphertext. It cannot see plaintext, and there is no account that could recover the secret by user.

When the recipient opens the read page, the tab first asks whether ciphertext is still there. That check does not spend a read. Only after Open and view does the browser fetch ciphertext and decrypt it locally with the key after #. After a successful decrypt, the fragment is still in the address bar by default. Closing the tab or leaving the page wipes the plaintext box — the read page listens for pagehide — but it does not rewrite the address. Only Clear this page calls history.replaceState and collapses the current URL to path plus query, dropping # and the key after it. WHATWG defines replaceState as replacing the current session-history entry, not appending a new one; see the History API. Close the tab after that, and Recently closed tabs restore an address that no longer has the key.

Whether ciphertext on the server is already gone still depends only on the create-time count and TTL. Clearing this page does not spend an extra read, and it does not save one. While reads remain, anyone who has the full link can still click Open and view. After the count is used up, the full link only opens the burned state — and the address can still sit in session history, bookmarks, and chat. Why pasting the same link into a preview-generating chat does not always spend a read is Why pasting a burn-after-reading link into a chat that generates a preview does not always use up the read. This article covers the recipient’s own browser record, not the card in the channel.

The person who can press the shortcut is whoever can use this browser profile. A shared PC, an unlocked desk, or a browser that was borrowed and never signed out turns Recently closed tabs into a second way to fetch the link. Clearing the Recently closed list or clearing history blocks that shortcut. It does not block a full URL already copied into chat, a ticket, or a screenshot. Burn-Link limits how long ciphertext lives on the server, and how many times it can be read. It does not decide who can still see the address in a local record.

After the read count is used up, opening the link from history usually only shows the burned state. That is not “history is now safe.” An admin, a coworker, or you can still read from that string that an id once existed and that someone used a fragment as a key. Long-term storage or multi-device sync belongs in a dedicated password manager. UsePwd has no accounts and no vault, and cannot recover a lost link by user. Identity is explained on About.

Files are a third path. A local backup of a single file up to 5 GB goes through File Encryption Box, writes .lock / .enc, and does not upload the file by default. Generate the passphrase itself in the Password Generator between 6 and 128 characters, then check strength in Password Audit. Those pages, like this article, open immediately. Do not read “the fragment never enters server logs” as “closing the tab destroys the key.” Logs, session history, and chat history are not the same layer.