The # in the URL That Keeps Your Key Secret

Every link generated by mboxly.app looks something like this: mboxly.app/s/a1b2c3#Kx9mP…. The part after the # is called a URL fragment — and it behaves very differently from everything before it.

By design, browsers never include the fragment in HTTP requests. When you open a link, your browser sends the path and query string to the server — but strips everything after # and keeps it locally. This is a fundamental web specification, not a clever workaround.

mboxly.app exploits this deliberately. The decryption key lives inside the fragment. Our server receives the request, delivers the encrypted ciphertext, and has no technical way to see the key. Even our own access logs contain no trace of it.

The recipient's browser extracts the key from the fragment, downloads the ciphertext, and decrypts the message entirely on the client side. The plaintext never touches our infrastructure at any point.

This also changes the threat model in a very practical way. A reverse proxy, CDN, load balancer, analytics tool, or web server log may record the path of the message URL, but not the secret fragment. That means infrastructure providers can observe that a message exists without being able to decrypt it. For a zero-knowledge service, that separation matters more than marketing claims — it is an architectural boundary enforced by the browser itself.

This single browser behaviour is what makes zero-knowledge architecture possible — no complicated key-exchange protocols, no external key servers, no trust assumptions about the service provider.