How to share a password or secret safely

Toolkit Guides · Updated July 2026 · 6 min read

Sooner or later everyone has to hand a secret to another person — the Wi-Fi password to a house guest, a login to a contractor, an API key to a teammate. The reflex is to paste it into whatever chat window is already open. This guide walks through what actually happens to that message, why deleting it afterward fixes almost nothing, and how to hand over a secret so that it stops existing once it's delivered.

Where a pasted secret actually goes

A password typed into email or chat doesn't travel from your screen to theirs — it gets stored, then copied. The message lands on the provider's servers, often readable by the service itself unless the app is end-to-end encrypted. From there it syncs to every device the recipient owns: phone, laptop, tablet, the old iPad in a drawer. It's swept into automatic backups on both sides — yours and theirs — and into exports and archives neither of you will ever audit. Forward the thread or quote a reply and the copies multiply again.

Worst of all, it's indexed. Try searching an old inbox for the word "password" — the results are usually mortifying. A credential pasted into chat in 2019 is still sitting in someone's search results today, filed and waiting for whichever account gets compromised first.

Deleting your copy deletes exactly that: your copy. The recipient's copy, the server's copy, and every backup copy survive. Once a secret has been written into a system built to remember, you don't get to un-remember it — which points at the real design goal: the secret should pass through, not settle in.

Three everyday handoffs, done better

The Wi-Fi password for a guest. Low stakes, but chat history is forever and network passwords rarely change. Show a QR code instead: the QR code maker generates a Wi-Fi code locally in your browser, the guest's phone camera joins the network directly, and the password never appears in any message log.
Credentials for a contractor. First choice: don't share your account at all — create a separate user with only the access the job needs, so you can revoke it cleanly. When a service allows only one login, send the password through a one-time encrypted link (below), name the account in your normal channel, and rotate the password with the password generator the day the job ends.
Handing off an account for good. Change the password first, so you're not exposing one you use anywhere else. Send the fresh credential through a one-time link, and have the recipient change it again on arrival. Neither side ever knows the other's final password — which is exactly right.

Three principles for any secret handoff

Minimize copies. Every copy of a secret is a separate chance for it to leak later. The ideal handoff creates one temporary copy in transit and zero permanent ones.
Expire fast. A secret in transit should have a shelf life. If the recipient never picks it up, it should quietly cease to exist rather than wait in an inbox indefinitely.
Split the channels. Don't send the lock and the key through the same pipe. If the password travels in an encrypted link, send the username — and what the password is for — in the ordinary channel. Anyone skimming one channel gets half a secret, which is none of one.

How a one-time encrypted link works

A one-time link is the tool built around those three principles, and it's worth understanding the mechanics, because the privacy comes from architecture rather than promises.

When you create one, your browser generates a random encryption key and encrypts the secret locally with AES-GCM — the same authenticated encryption that protects HTTPS traffic — before anything is transmitted. Only the resulting ciphertext is stored on the server. The decryption key rides along in the link after the # symbol, and that placement is the trick: browsers never send the fragment part of a URL to any server. So the server holds scrambled bytes it cannot read, and the only complete copy of the secret is the link itself, in transit.

When the recipient opens the link and clicks reveal, the server hands over the ciphertext and deletes it in the same atomic operation. The browser then decrypts locally using the key from the fragment. Read once, gone forever — a second visit finds nothing. Unopened links self-destruct too, on a timer you pick (a day to 30 days for text; small files, up to about 3 MB, expire within a day). And because revealing requires a deliberate click, a chat app's link-preview robot can't accidentally burn the secret while unfurling the URL.

The self-destruction buys you something subtler than tidiness: tamper evidence. If your recipient says "it told me the secret was already viewed," you know someone else got there first, and you rotate the credential immediately. A password sitting in a chat log can be read by a third party silently, with no signal to anyone. A one-time secret cannot be read silently — reading it is what destroys it.

Try it: the one-time secret link encrypts text or a small file in your browser, stores only ciphertext, and destroys it on first read. Create a test link and open it twice to watch the second attempt fail.

The honest limits

No handoff method survives the recipient's side of the transaction. Once the secret is revealed, it exists on their screen, in their clipboard, and wherever they choose to keep it — possibly a sticky note. Encryption in transit can't manage other people's habits; if the secret is important, say a word about where it should live (ideally their password manager, not their notes app).

A one-time link is also a bearer instrument: whoever holds the full link first, wins the race. That's precisely why the expiry timer and channel-splitting matter — a link that dies in a day, carrying a password whose username traveled elsewhere, is a poor prize for someone rifling through a mailbox a month later. If the channel you're using might be actively watched in real time, split more aggressively: for the truly cautious, the text encryptor lets you encrypt a note with a passphrase you speak over a phone call, so the ciphertext and the key never share a channel at all.

And one habit to drop permanently: sending username and password together in the same message, whatever the message is. Pairing them is most of an attacker's work done for free.

For anything ongoing, use a shared password manager

One-time links solve handoffs — a secret crossing from one person to another, once. They are the wrong tool for custody: a team that shares logins every week shouldn't be minting links every week. That's what shared vaults in password managers are for: each person gets their own access, additions and changes sync to everyone, and when someone leaves you revoke their access instead of rotating every password over group chat. Families can do the same with shared collections for streaming and household accounts.

The rule of thumb that covers nearly every case: secrets at rest belong in a manager; secrets in motion belong in something that expires. Chat and email are neither — they're the office whiteboard, permanently photographed. All of the tools above run locally in your browser, so the secret isn't handed to yet another server on the way — here's how that works and how to verify it. And if the password you're about to share is Winter2026, share a better one: what makes a password strong takes eight minutes.