b2KIT

Dead Drop Encrypted Message

Create encrypted messages encoded as URL fragments. The secret never touches a server - decryption happens locally.

Tested tool guide Tested browser tools Checked August 16, 2026

What Dead Drop Encrypted Message does and how it behaves

A complete share link is the container for the secret. Dead Drop Encrypted Message encrypts entered plaintext and places the encoded result after the # in a generated URL. Opening that full URL lets the recipient's browser recover the message locally, while normal navigation does not send the fragment to the web server. The important surprise is that "dead drop" does not mean automatically one-time or unrecorded. Anyone or any application that obtains the complete URL may preserve it, so the link itself must be treated as sensitive.

How the result is produced

1

Fragment boundary

The portion of a URL beginning with # is its fragment identifier. URI processing separates that fragment before the resource is requested, so the ordinary page request contains only the part before #. This tool uses the browser-visible fragment to carry the encoded encrypted message. That keeps the payload out of the navigation request, but it does not conceal which site or page was visited.

2

Create and open

During creation, the tool encrypts the plaintext in the current browser and serializes the result into the generated link's fragment. When the recipient opens the complete link, the tool reads that fragment and performs decryption locally. Because no server stores the message, the link is the handoff artifact. The # and every character following it must survive copying; truncation or rewriting can make the message unreadable.

Good uses

  • Passing a temporary password or recovery code without placing readable secret text in the message body.
  • Sending a short confidential note through a channel that preserves complete URLs, including their fragments.
  • Moving a secret between your own browsers or devices using the generated link as a copy-and-paste handoff.

Limits and checks

  • The generated link is not inherently self-destructing. A recipient, browser, clipboard manager, chat application, or screenshot can retain a copy.
  • Fragment handling keeps the payload out of the normal page request, but it does not make the complete URL safe to expose. Treat the full link as confidential.
  • Long plaintext produces a longer URL. Browsers, messaging systems, QR workflows, and link scanners can impose different length limits or alter URLs, so this tool is better suited to short messages.

Common questions

Does the server receive my secret?

No. This tool performs encryption and decryption in the browser and does not upload the message. In normal URL navigation, the browser also excludes the fragment, including the leading # and everything after it, from the request sent to the page's server. The complete URL can still be visible to your browser, clipboard, history, and whichever application you use to share it.

Is the message available only once?

No. A browser-only link cannot enforce global single-use access because another copy of the complete URL can be opened again. Closing the page or deleting your local copy does not invalidate copies held elsewhere. If strict expiration, revocation, recipient authentication, or proof of deletion is required, this link alone does not provide those controls.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools