Open source · Zero knowledge · No accounts

Send a secret.
It opens once.

SendKey turns a password or API key into an encrypted one time link. The first open reveals the secret and destroys it. The key never touches the server, so nobody can read it in between. Not even us.

New secret

encrypts locally
0 bytes

AES-256-GCM·key stays in the # fragment·burns on first read

Need to receive one instead? Ask for a secret →

How it works

The key never touches the server

This is not a policy you have to trust. It is how URLs work.

01

Encrypted in your browser

Your browser generates a fresh 256 bit key and seals the secret with it. Only the sealed bytes are uploaded. The key stays with you.

02

The key rides the fragment

Everything after # in a URL stays inside the browser. The key lives there, so it reaches your recipient without ever crossing the server.

03

The first open burns it

Reading and deleting happen as one atomic step on the server. After that, the link is dead for everyone.

Public id The only thing the server ever sees.
Decryption key Never sent to any server, by how browsers work.

Our end to end tests fail the build if the fragment ever appears in a request.

Security

Nothing worth stealing, no one to trust

If the database leaked tomorrow, the thief would hold random bytes and no keys.

Encrypted before upload

AES-256-GCM runs on your device. Only sealed bytes ever leave it, and only sealed bytes are stored.

Burns exactly once

Read and delete are one atomic step. If fifty people click at the same moment, exactly one sees the secret.

Expires on its own

Unopened secrets wipe themselves after one hour, one day, or seven days. Nothing waits around.

Optional passphrase

A second lock, checked on the recipient's device. A typo burns nothing, and there is nothing for attackers to guess against.

No accounts, no tracking

No signup, no cookies, no analytics, no third party scripts. The page cannot talk to anyone but this server.

Open source

A small Go codebase with zero dependencies, MIT licensed. Audit it in an afternoon, host it anywhere.

Command line

The same tool lives in your terminal

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.

Reads stdin, writes stdout, fits into pipes
Encrypts locally, before anything touches the network
Self hosts with a single command
$ go install github.com/realanshuman/sendkey/cmd/sendkey@latest
~/ sendkey
$ sendkey send "AKIA-EXAMPLE-SECRET-KEY"
one-time link (burns after 1 view, expires in 24h):
https://sendkey.xyz/s/H6847TzgXETB#HLsZDskZ-NQFE5xolu…

$ pass show prod/db | sendkey send -ttl 1h -views 2

$ 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
FAQ

Straight answers

Can you read my secret?
No. The secret is encrypted in your browser before it is uploaded, and the key never reaches us. It lives after the # 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.
What if someone else opens the link first?
Then they see the secret, and your recipient sees a dead link. That sounds scary, but it means you always find out. Send the link over a channel you trust, keep the expiry short, and add a passphrase for anything serious.
What happens if nobody opens the link?
It expires on its own after the time you chose: one hour, one day, or seven days. Expired secrets are wiped whether or not anyone ever opened them.
Why is the passphrase checked in my browser?
A server side check would have to either destroy the secret on a typo, or give attackers something to guess against. Checking on your device means you can retry as often as you need, and nobody gets to guess.
What does SendKey not protect against?
Whoever holds the link before it is opened can read the secret, so treat the link with the same care as the secret itself. And like every tool that encrypts in the browser, it relies on the page being delivered honestly. If that matters for you, use the CLI or host it yourself.
Can someone send a secret to me instead?
Yes. An ask link flips the direction. Your browser generates a keypair; the link you share carries the public half, and whoever opens it answers into an encrypted mailbox that only your browser can unlock. One answer per ask, burned on first read, and both sides see the same pixel fingerprint so you can compare keys out of band. Create one at sendkey.xyz/ask.
Can I host it myself?
Yes, and for anything serious you should. It is one Go binary with no dependencies: run 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.

Stop pasting secrets into chat

Chat history is saved, synced, and backed up forever. A SendKey link opens once and dies.