Encrypted Share Link

What this tool does

Encrypted Share Link encrypts a message with a password (AES-256-GCM via PBKDF2) and encodes the result into this tool’s own URL fragment (the part after #), which browsers never include in any HTTP request, meaning no server, including the one hosting this page, ever sees the message or password.

URL fragments, the part of a web address after a # symbol, are deliberately never sent to a server in an HTTP request, browsers keep them entirely client-side, a quirk this tool uses to create a shareable link whose encrypted contents genuinely never touch any server, not even the one hosting the page itself.

Create mode encrypts your message with AES-256-GCM using a password-derived key, encodes the ciphertext into the URL fragment, and gives you a link to share; opening that link elsewhere automatically detects the embedded data and prompts for the password to decrypt it, entirely in the recipient’s own browser.

How to use Encrypted Share Link

1. Enter the Message to share and a Password.
2. Press Create encrypted link and copy the resulting link.
3. Send the link and the password through two separate channels.
4. The recipient opens the link, enters the password, and the message decrypts locally in their browser.

Tips for better results

• Always share the password through a different channel than the link itself (e.g. link by email, password by text message); if both travel together through the same channel, intercepting it defeats the whole purpose.
• Because the data lives in the URL fragment, which browsers never transmit, no server, not Toolew’s, not any link-shortening or analytics service the link might pass through, ever sees the plaintext message or the password.
• Toggle "burn after reading" to clear the encrypted data from the browser’s address bar immediately after a successful decryption on the recipient’s side, reducing the chance it lingers in their browser history.
• There is no password recovery; if it’s lost, the message encoded in that link becomes permanently unreadable, this is an inherent trade-off of real encryption, not a limitation specific to this tool.

Common use cases

• Sharing a sensitive note or credential through a link without any server ever seeing its contents.
• Sending a password-protected message through a channel you don’t fully control or trust.
• Creating a link that can be opened and decrypted without any backend service or database.
• Learning how URL fragments can be used for genuinely client-side-only data transfer.

Common mistakes to avoid

• Sending the password through the exact same message or channel as the link; that undermines the separation this approach relies on for its security benefit.
• Assuming the link itself is safe to post publicly just because the contents are encrypted; anyone who obtains both the link and the password can decrypt it, so still treat the link with the same care as the message itself.
• Forwarding the link through a service that strips or alters URL fragments; while uncommon, some link processors can interfere with the fragment, always test a link once after creating it.