A password, an API key, or a whole file becomes one encrypted link. The first open reveals it and destroys it, and the key never touches the server. Nobody can read it in between. Not even us.
Your link is ready. It works exactly once.
The part after # is the decryption key. Browsers never
send it to any server, so it stays between you and your recipient.
If you lose the link, the secret cannot be recovered.
Waiting to be opened…
Send one, ask for one, or ship a whole file. Same crypto underneath, same burn at the end.
Paste a password or key, get a one time link. The first open burns it, and everyone can see that it burned.
Send one →Up to 8 MB, split into chunks and sealed in your browser, with the chunk order cryptographically pinned. The link behaves exactly like a text secret.
Send a file →Flip the direction. Your browser makes a keypair, and whoever opens your ask answers into a mailbox only this browser can unlock.
Create an ask →Every mode shares the dials: a passphrase second lock, expiry from one hour to seven days, and one to five views before the burn.
Everything is sealed in your browser before upload. The rest is not a policy you have to trust; it is how URLs work.
Nobody has opened this one yet. It is holding exactly one view.
PlaintextAKIA4T7QZ2X9V0RB1MPD
Decrypted in this tab, with the key after the #. The
server handed over ciphertext and forgot it in the same step.
404. Same link, second visitor. There is nothing left on the server to hand over, and no copy of the key anywhere to ask for.
Our end to end tests fail the build if the fragment ever appears in a request.
Everything after # in a URL stays inside the browser.
The key lives there, so it reaches your recipient without ever
crossing the server.
Read and delete are one atomic step. If fifty people click at the same moment, exactly one sees the secret.
Unopened secrets wipe themselves after one hour, one day, or seven days. Nothing waits around.
A second lock, checked on the recipient's device. A typo burns nothing, and there is nothing for attackers to guess against.
No signup, no cookies, no analytics, no third party scripts. The page cannot talk to anyone but this server.
A small Go codebase with zero dependencies, MIT licensed. Audit it in an afternoon, host it anywhere.
One static binary is the server, the site, and the client. A link made in the terminal opens in the browser, and the other way round.
$ go install github.com/realanshuman/sendkey/cmd/sendkey@latest
$ sendkey send "AKIA-EXAMPLE-SECRET-KEY" one-time link (burns after 1 view, expires in 24h): https://sendkey.xyz/s/H6847TzgXETB#HLsZDskZ-NQFE5xolu… $ sendkey send -file backup.tar.gz encrypting and uploading: 16/16 chunks https://sendkey.xyz/s/Qm93kd0Xw1Tz#R6cdQpWvZ2xNb4Ml… $ sendkey get 'https://sendkey.xyz/s/H6847…#HLsZ…' AKIA-EXAMPLE-SECRET-KEY $ sendkey get 'https://sendkey.xyz/s/H6847…#HLsZ…' sendkey: server: this secret has expired or already been viewed
# in
the link, which is the one part of a URL browsers never send to any
server. What we store is scrambled data we cannot open.
Waiting to be opened and switches to the exact time
the moment someone reads it, with no reload. Keep the tab open to
watch it. The record that carries the timestamp holds no
ciphertext at all: opening a secret still destroys it, the
receipt is only the fact that it happened.
sendkey send -file report.pdf.
sendkey serve and you are live.
Secrets stay in memory, or in Redis when you point it at one. It
also deploys to Vercel unchanged.
Chat history is saved, synced, and backed up forever. A SendKey link opens once and dies.