What the browser sends

In a URL such as https://example.com/note/abc#KEY, the browser requests /note/abc from the server. The fragment beginning with # is interpreted locally and is not included in the HTTP request. Server access logs, reverse proxies, and application routers therefore receive the note identifier but not the fragment through the normal request path.

Client-side code can read the fragment after the page loads, derive or import a key, fetch ciphertext by identifier, and decrypt locally. The server can store a ciphertext blob without possessing the corresponding key.

What this does not protect

The complete link still contains the key. It can leak through clipboard history, screenshots, browser synchronization, chat retention, endpoint malware, extensions, or a recipient forwarding it. Client-side telemetry and error reporting must be configured not to capture full URLs. The page must also avoid sending the fragment to another service through custom code.

A malicious or compromised server could deliver JavaScript that exfiltrates the fragment the next time a recipient opens a note. Strong deployment controls, a restrictive Content Security Policy, dependency discipline, and independent review matter even in a so-called zero-knowledge design.

Use authenticated encryption

Confidentiality alone is insufficient. An authenticated mode such as AES-GCM detects ciphertext modification. Each encryption needs a unique nonce for the chosen key, and the design must define exactly what metadata is authenticated. Random keys should come from the browser’s cryptographic random source, never a general-purpose random function.

The fragment separates key delivery from the request path; it does not replace transport security. HTTPS is still required to protect the page code, ciphertext, and note identifier in transit.

Design the whole lifecycle

Limit how long ciphertext exists, consume records atomically, prevent caches from retaining responses, minimize logs, and make failures safe. A URL fragment is a useful architectural primitive—not a security guarantee by itself.

Sources and review basis

This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references: