Encrypted Link Share
A browser-mode secret-sharing tool. Type your secret, get a link that encrypts everything client-side with AES-GCM 256-bit via the Web Crypto API. The encryption key lives in the URL fragment (after the #) — per HTTP spec, browsers never include fragments in network requests, so the key stays in the recipient's browser. No account is required. The trade-off compared to Privnote-style services: this tool does not maintain a database of secrets in browser mode, so we cannot enforce a "view once and delete" rule — the link will decrypt as many times as anyone with it tries.
How to use
Up to ~4 KB of text fits comfortably in a URL across all major browsers.
A second factor: the link gets decoded with the key in the URL, then the password layer is peeled. Share password over a different channel.
Send via email, Slack, Signal, SMS — whatever channel you trust. The receiver opens the link in any browser.
No install, no account. Just click the link and (if set) enter the password. The secret is decrypted locally and shown.
Send a secret to someone via an encrypted link — encryption runs in the browser, no account needed
Options
How this works (and what it does NOT do)
- AES-GCM 256-bit encryption with a random key generated in your browser.
- The encryption key lives in the URL fragment (after the #) — fragments are never sent to a server by any browser.
- No account, no database, no third-party service: anyone with the link can decrypt the secret.
- This is not true "one-time" — anyone with a copy of the link can decrypt as many times as they want. The "burn after reading" indicator is only a local hint in the viewer's browser.
- For true one-time semantics use a service with server-side storage and delete-after-read. For privacy/no-server, this tool is the right trade-off.
Open the encrypted secret
Features
FAQ
Can we read your secret on the server?
In browser mode — no. The encryption key lives after the # in the URL, and per HTTP spec browsers never include fragments in network requests, so the key never reaches our server. The encrypted blob arrives in the URL path (so our server logs may briefly record the ciphertext via standard nginx access logs), but without the key the ciphertext is AES-GCM-256 and not decryptable.
How is this different from Privnote?
Privnote stores the encrypted blob in a database and deletes it after first view. In browser mode this tool does not use a secrets database — the blob is in the URL itself, so we cannot enforce "view once". The trade-off: the encryption key never reaches our server, but the link is reusable as long as someone has it. (The server-stored mode of this tool is more like Privnote.)
Why is the URL so long?
It contains the entire encrypted secret, the AES IV, optional salt, and the key. The longer the secret, the longer the URL. Around 4 KB of text produces a ~6 KB URL — still acceptable in any modern browser.
Is the password really needed?
No — the link alone is fully encrypted. The password is an extra factor in case the link leaks (chat history, leaked Slack message). With both layers, an attacker needs both the link and the password.
How long does the link work?
In browser mode: as long as someone has the URL. There is no database state to enforce an expiry, so treat shared links as durable until you trust they have been deleted from every recipient device. (In server-stored mode an explicit TTL applies — see "Expires after".)
Can you make a true "view once" version?
Yes — that is the server-stored mode. It uses server-side storage with delete-after-read, which has different trust assumptions (you have to trust the server). The browser mode (ciphertext in URL) ships alongside as a no-database option.
We can — and it's free! Just send us a quick message with your idea. If you'd like to discuss it in detail, leave your email and we'll get back to you. You can stay anonymous.
