We have all done it. A colleague needs access to a shared account, so you paste the password into Slack or email and hit send. "I'll delete it later," you promise yourself.

You don't. And even when you do, the copy you deleted was never the only one. The problem isn't discipline — it's the medium. Email and chat were built to keep messages, not destroy them. If you want to send a password safely, you need a transport that forgets on purpose.

Why email and chat leak credentials

A password pasted into a normal messaging channel doesn't exist in one place. It fans out into copies you don't control.

It sits at rest, often readable. Your message lands in your Sent folder, the recipient's inbox, and any mail server or backup in between. Email between providers may be TLS-encrypted in transit, but it is routinely stored in plaintext at rest. Anyone who later reads that mailbox — a thief with the laptop, an attacker with a stolen token, an admin doing "maintenance" — reads the password too.
Chat keeps durable logs. Slack, Teams, and WhatsApp retain history by design. A credential you shared in March is still sitting in that DM in December. If the recipient's session is hijacked or their device is stolen, the search bar does the attacker's work for them.
Copies multiply. Messages get forwarded, quoted in replies, screenshotted, and indexed by desktop search and corporate eDiscovery tooling. You cannot un-send or reliably purge any of them.
The reply-all disaster is real. One wrong recipient — or one autocompleted name — and a production credential lands in the whole team's inbox. It happens more often than anyone admits.

We wrote a longer breakdown of exactly how these channels betray you in why email is the worst way to send a password. The short version: the leak isn't hypothetical, it's the default.

The fix: make the transport self-destruct

The safest way to move a secret is to send it through something that erases itself after one use. That's the whole idea behind a one-time secret link.

Here's the mechanism, because the mechanism is what makes it trustworthy:

The password is encrypted in your browser before anything leaves your device (SnapSend uses AES-256-GCM).
The decryption key is placed in the link's # fragment — the part after the hash. Browsers never send the fragment to the server, so the relay only ever stores ciphertext it cannot read.
The recipient opens the link, their browser pulls the key from the fragment, decrypts locally, and shows the secret.
On that first read, the ciphertext is deleted from the server. Anyone who opens the link afterward — a curious admin, an attacker replaying a leaked URL — gets a 404. The secret is gone.

This is what "zero-knowledge" should mean in practice: the service operator can't hand over your password because they never had it in a readable form. If you want the deeper version, see zero-knowledge encryption explained.

How to send a password securely, step by step

Generate a strong password first, if you're creating one. Don't reuse your dog's name or Summer2026!. A random string removes the guessing attack entirely. SnapSend's password generator produces high-entropy strings you can drop straight into the next step.
Encrypt it into a one-time link. Paste the credential into a send-a-password tool (or the general-purpose text share) and let the browser encrypt it. Set an expiry — say 24 hours — so the link dies even if nobody ever opens it.
Send the link, not the secret. Drop the resulting URL into email or chat. The link is safe to log because it's useless once read or expired.
Confirm receipt out of band. For anything important, ping the person on a different channel: "sent you the link, open it now and tell me it worked." If they say the link is already dead when they first click, treat that as a possible intercept and rotate immediately.

A concrete example

Say you're handing off the login for a shared analytics account.

Send the username by email: analytics-shared@company.com.
Generate a one-time link for the password and send that over Slack.
The recipient opens the Slack link once, reads the password, and it self-destructs.

Now no single channel ever held both halves. An attacker who compromises the email thread has a username and a dead link. An attacker who scrapes old Slack history finds a URL that 404s. Neither is enough to log in.

Requesting a password safely (the reverse case)

Sending is only half the problem. Sometimes you need someone else to hand you a secret — a client's API key, a vendor's admin password. Don't tell them to email it; that just moves the leak upstream. Instead, send them a secure receive link where they type the secret into an encrypted box that only you can open. They don't need an account, and the plaintext never touches their outbox or your inbox.

Common mistakes to avoid

Sending the username and password in the same message. Split them across two channels. One compromised channel should never be enough.
Using a "private" pastebin as a password tool. Most paste sites store plaintext and keep the URL live forever. That's email's problem with extra steps.
Setting no expiry. A one-time link that's never opened can linger for weeks. Always set a hard expiry so an unread secret still dies on a clock.
Reusing the same secret after a leak scare. If you suspect a link was intercepted, rotate the credential. A password that might be exposed is exposed.
Skipping the confirmation. "Did it work?" on a second channel is your cheapest intrusion detector. If the link was already burned when the real recipient arrived, someone else got there first.

Quick checklist

[ ] Password is strong and randomly generated
[ ] It's encrypted client-side into a one-time link, not pasted as plaintext
[ ] A hard expiry is set (hours, not weeks)
[ ] The link is sent separately from the username
[ ] Receipt is confirmed on a second channel
[ ] The credential is rotated if anything looks off

FAQ

Is a one-time link safe to send over email? Yes — that's the point. The link contains only ciphertext plus a decryption key in the fragment, and it stops working after the first open or at expiry. Even if the email is later breached, the link is already dead.

What if the recipient never opens it? It expires on its own. Set the shortest expiry that's still practical for the recipient's timezone and schedule.

Is this better than a password manager's built-in sharing? For teammates who already share a vault, use the vault. One-time links shine when the other person isn't in your vault — contractors, clients, vendors, or a colleague you just need to hand one credential to, once. For the team-vault side of this, see sharing passwords securely with your team.

Can the service read my password? Not if it's genuinely zero-knowledge. With the key living in the URL fragment, the server only ever stores data it can't decrypt.

Security here isn't about being more disciplined than everyone else. It's about picking a transport that fails safe. When you need to hand someone a credential, encrypt it into a self-destructing link with SnapSend's password sender — no account required, and the secret is gone the moment it's read.