Why URL hash fragments never reach the server

When ops paste a temporary password into chat, or support forwards an admin URL with a token, the real fear is rarely “the other person can see it.” It is that every hop may keep a full copy of the link. Many people therefore assume: if a secret appears in the address bar, the server log must have a copy.

A full address splits into three parts. Scheme and host decide whom the browser talks to. Path and query parameters decide which resource, and those two appear on the HTTP request line. Characters after the hash are the fragment. They originally told the browser to scroll to an anchor; later, front-end scripts also read them with location.hash on the device. The server neither receives that string nor should use it for routing or auth.

Putting a key after # does not invent a new cipher. It uses a sending boundary browsers have long followed: one link can carry an id for the server and a key that stays in the current tab. UsePwd Burn-Link uses that boundary. Create and read both work on open; neither side registers. The server only stores ciphertext. Plaintext and the key are not sent as request bodies by default.

This is how the URL standard has long worked. It is not a private convention of one site, and it is not “the server promised not to look.” “Can the server see it” here means: after TLS terminates, can the origin or a reverse proxy you control read that field from this HTTP request. It does not cover a compromised device, an extension that can read the page, or someone saving a screenshot.

On create, the current tab uses Web Crypto to generate a random key, encrypts the text with AES-256-GCM, and sends ciphertext to the server. The returned id goes in ?id=; the key is appended only after #.

The read page is public to the recipient. When they open s.html?id={id}#{key}, the browser fetches ciphertext or status with id, then decrypts with the fragment key kept locally. After the create-time read limit, the server deletes the ciphertext and the link cannot be read again. The recipient also does not register. The read page is a temporary ciphertext view, not a site index entry; for product capability, return to the create page or the check steps in this article.

A fragment key solves the “server logs and request line” layer. It does not solve “whom you sent the full link to.” Chat apps, email, and ticket systems keep the whole address you paste. Anyone with the full link has both the id and the key. Burn-Link limits ciphertext lifetime and read count on the server. It does not stop a recipient from taking a screenshot or forwarding.

How this differs from a query-parameter scheme

Some one-time links put decrypt material in ?k=. That is simple, but every open writes the key onto the request line, so CDN, WAF, and origin access logs can keep a copy. A fragment adds a hash and, in return, even a host that logs the full URL is missing the half that unlocks the ciphertext. The cost is that you must tell the recipient to copy the complete link, not only the part before the hash; without # and after, the read page can fetch ciphertext and cannot unlock it locally.

That is also why this article does not describe Burn-Link as a “password manager” or a recoverable safe. UsePwd has no accounts, no vault, and cannot recover a secret by user. If the link is lost, the fragment is truncated, or the read count is used up, the server cannot restore plaintext for you. Identity is explained on About.

If the secret only needs a limited number of reads and both sides can open a browser, use Burn-Link: plaintext is encrypted locally, the id goes in ?id=, the key goes after #, and it works immediately — no sign-up. After create, compare once in the Network panel: the POST body is ciphertext, and the GET URL has no fragment. If you actually need long-term storage, multi-device sync, or recovery, that is outside this site—use a dedicated password manager, and do not treat UsePwd as an account system.

If the secret should never enter a third-party page, do not create a link: say it in person, use offline media, or stay inside an end-to-end channel you already have. A fragment scheme reduces “keys in server logs,” not “everyone who can see a screen.” Separating those layers keeps a URL-mechanics article from being read as a product warranty.

Whether the password itself is strong is a different question. Generate a 6–128 character random secret in the Password Generator; to check strength locally against the public leaked-password list shipped with the page, use Password Audit. The audit is not a web-wide lookup, and the password is not uploaded. Before you send a link or ticket text, use Privacy Cleanup to strip trackers or redact. Those pages, like this article, work immediately — no sign-up. The top bar only has a language switch.