This tool is named for the job people come looking for, so it should be clear at the outset what it does and does not do.
It does not burn after reading. Deleting a secret after one retrieval requires a server that holds the ciphertext, counts reads, and deletes it — which means trusting that server with your secret and its retention policy. This page has no server, by design, so it cannot make that promise. Any tool that offers burn-after-reading is asking you to trust an operator you cannot audit.
What it does instead is solve the adjacent problem honestly: it removes any single channel's ability to expose the secret.
How the split works
The secret is encrypted in your browser with AES-256-GCM under a key generated in this tab. You get two values:
- Channel 1 — the link. The ciphertext, carried in the URL fragment. Everything after
#is never sent to a web server by any browser, so even the host of your viewer page never receives it. - Channel 2 — the key. The raw AES key, as a separate short string.
Send them by different routes. The link in a ticket, the key by phone. The link in email, the key in Signal. An attacker who compromises one channel gets nothing usable: ciphertext without a key is noise, and a key without ciphertext is a random number.
When this is worth doing
When you must move a credential through a channel you do not fully trust, and you have a second independent channel available. That is the whole scope.
If you have one trustworthy channel, use it directly — this adds ceremony without adding security. If both your "separate" channels are the same Slack workspace, you have split nothing.
The better answer, when available
Do not transfer the secret at all. Have the recipient generate their own credential and grant it the access it needs. A key that was never in two places cannot leak from either. Provisioning is more work than pasting a password, and it is the reason mature systems have per-consumer credentials.
Where transfer is unavoidable, treat the secret as compromised on a timer: rotate it after the recipient has used it. A credential that travelled through email should not still be valid next quarter.
Frequently asked questions
Why not put both the ciphertext and the key in the same link?
Then the encryption is decorative — anyone with the link has both halves, exactly as if you had sent the plaintext. The separation is the entire security property.
Is the URL fragment really never sent to the server?
Correct. The fragment is a client-side construct: browsers strip everything from # onward before making the request. It does not appear in server logs. It can still appear in browser history and in anything that captures the full URL, so the link is not zero-risk — only server-invisible.
What happens if I lose the key?
The ciphertext is unrecoverable. AES-256-GCM with a lost key is exactly as strong as advertised. Generate a new package.
Does the recipient need a special page to decrypt it?
They need something that reads the fragment and performs the AES-GCM decryption — a small static page you host, which is what the viewer URL field is for. The AES encryption tool can also decrypt the envelope manually.