Share a password or API key without leaving it in a chat log
A secret pasted into Slack, email or a ticket stays there — searchable, backed up, exported on the way out, and readable by anyone who later gets into that account. This clipboard is the opposite shape: the content is encrypted in your browser before upload so the server only holds ciphertext, nobody gets in without your explicit approval, and the whole thing is destroyed 24 hours after the last activity.
- AES-256-GCM in your browser
- You approve each person
- Gone in 24 hours
Start a clipboard
Enters automatically once all six digits are in
Content is encrypted in your browser before upload — the server never sees plaintext. Destroyed after 24 hours of inactivity.
How to share a password securely
Four steps, and the third one is the one people skip.
Create a clipboard
Your browser generates a 256-bit content key and keeps it. The server gives you a 6-digit code and never sees the key.
Pass the code over a different channel
Say it on a call, read it across the desk, send it in an app you are not sending the secret through. A code delivered next to the secret protects nothing.
Check the confirmation code, then approve
When they enter the code, both screens show the same 4-character confirmation code. Matching codes mean the key exchange is happening with the person you are talking to — not with someone else who guessed the digits.
Paste the secret, then delete it
It is encrypted before it leaves your browser. Once they have copied it, delete the item — or let the clipboard destroy itself.
What this actually protects you from
Database dumps and backup snapshots
The server only ever holds a 6-digit code, hashed tokens, two public keys and ciphertext. A leaked dump or an old backup contains nothing readable.
Chat history that never forgets
Message retention, mail archives and ticket exports keep credentials long after anyone needed them. Here, 24 hours of inactivity ends it, with no cleanup task to remember.
The wrong person receiving it
Knowing the code is not access. It puts someone in a queue you can see, with a confirmation code you can check against their screen before you let them in.
A forwarded link
There is no secret-bearing URL. The decryption key lives in the recipient's browser, not in the address bar, so a pasted link hands over nothing.
An admin reading over your shoulder
Workspace administrators can read channels. Server operators can read databases. Neither can read something their server never received in plaintext.
Forgetting to clean up
The expiry is not a setting you can leave on “never”. Every clipboard has a 24-hour ceiling on inactivity, always.
Versus pasting it into Slack or email
The difference is not that one is encrypted in transit — both are. It is what exists after the conversation is over.
| — | Slack, email, a ticket | This clipboard |
|---|---|---|
| Where the secret ends up | In a message store — indexed, searchable, backed up | In ciphertext the server cannot open |
| Who can read it later | Everyone in the channel, admins, and anyone who breaches the account | Only the two browsers that hold the key |
| How long it lives | Until someone remembers to delete it — usually nobody does | Destroyed 24 hours after the last activity |
| Who decides who sees it | Whoever happens to be in the thread | You, one request at a time, with a confirmation code |
| Forwarding it on | One click, and you will not know | No link carries the key — it has to be re-shared deliberately |
| Cleanup | Your responsibility, forever | Automatic, with no option to disable it |
What it does not protect you from
The page you are reading is JavaScript served by a server. A server that wanted your plaintext could ship a modified page that sends it — and no amount of client-side cryptography can prevent that, because the cryptography is part of what is being served. This is the hard ceiling of every browser-based end-to-end encrypted tool, including this one. What it buys you is protection against everything that happens after the fact: logs, dumps, backups, and a breach six months from now.
Metadata is also visible. The server knows a clipboard exists, roughly how large each item is, when it was written and from which IP address. It does not know what any of it says.
And a secret is only as private as the device it lands on. If the recipient pastes it into a note-taking app that syncs to a cloud, you are back where you started — that part is on them.
When to use something else
For a credential that more than two people need, or one that has to survive longer than a day, use a password manager with real sharing — 1Password, Bitwarden, Vaultwarden. This is a handover tool, not storage.
For a credential a machine needs, put it in a secrets manager and give the machine a role, not a string. And for anything that is about to be typed into a service you control: rotating the credential after the handover costs a minute and makes the whole question moot.
Questions about sharing secrets
Is this safer than sending a password over Slack?
For the risk that actually bites — the secret sitting readable in storage for years — yes, substantially. Slack encrypts messages in transit and at rest, but Slack can read them, admins can export them, and retention policies keep them. Here the server never receives plaintext at all, and the clipboard destroys itself after 24 hours of inactivity.
Can I send an API key, a token or a private key?
Yes. Anything text, up to 10,000 characters per item, so most keys, tokens, connection strings and even a short PEM block fit comfortably.
Does the recipient need an account or an app?
Neither. They open the page in any browser, type the six digits, and wait for you to approve. There is nothing to install and no email address to hand over.
What is the 4-character confirmation code for?
It is derived from the recipient's public key and shown on both screens. Its main job is telling requests apart when several people are knocking at once, and it also makes a crude key substitution visible — if the codes do not match, do not approve.
What happens if I close the tab or clear my browser data?
The content key lives only in that browser's local storage. Clearing site data makes the clipboard permanently unreadable, and the server cannot restore it. Copy out anything you still need first.
Can I revoke access after approving someone?
Yes. You can delete an individual item, clear everything, or remove everyone from the clipboard, which cuts off further reads immediately. What they already copied is, of course, already copied.
Is this a replacement for a password manager?
No, and it should not be. A password manager stores credentials for the long term with proper access control. This does the handover — the awkward thirty seconds where a secret has to travel from one person to another — and then gets out of the way.
Should I still rotate the credential afterwards?
If it is cheap to rotate, yes. Encryption narrows the window; rotation closes it. Treat any secret that has crossed a network as one more thing on the list to cycle.
Keep reading
- Private pastebinPaste text nobody can open without your approval.
- SecurityThe algorithms, the key exchange, and the honest limits.
Ready when you are
Create a clipboard, read the six digits to the other side, approve, and paste.