Encrypted Link Share
A privacy-first secret-sharing tool. Type your secret, get a link that encrypts everything client-side with AES-GCM 256-bit. The encryption key lives in the URL fragment (after the #), which browsers never transmit to servers. No account is required, no database stores anything, nothing is logged. The trade-off compared to Privnote-style services: there is no server, 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 — no account, no server, no third party
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
Is the secret really not on your server?
Correct. The encrypted blob and the key are both encoded into the URL — the encrypted blob in the path (which we receive) and the key after the # (which browsers never send). We physically cannot decrypt your secret even with full server access.
How is this different from Privnote?
Privnote stores the encrypted blob on a server and deletes it after first view. We do not store anything — the blob is in the URL. We cannot enforce "view once". The trade-off: full zero-trust, but the link is reusable as long as someone has it.
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?
Forever — as long as someone has the URL. There is no expiry because there is no server to enforce one. Treat shared links as durable until you trust they have been deleted from every recipient device.
Can you make a true "view once" version?
Yes — but it requires server-side storage with delete-after-read. That is a different tool with different trust assumptions (you have to trust the server). For now we ship the no-server 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.
