Use case
How to share passwords and sensitive info securely (without email)
Email and SMS keep everything they touch, forever, searchable. A disappearing chat gives you a safe handoff — and the ability to answer "wait, which account is this for?" without leaving a paper trail.
Share it securely — free, no sign-upWhy email and SMS are the worst channels for this
Email was never built to hold secrets — it was built to be kept. Every message you send sits in your sent folder, the recipient's inbox, and probably a backup or two, indexed and searchable for as long as either account exists. Send a password over email once, and years later it's still sitting there, findable by anyone who ever gets access to that inbox — an attacker, a subpoena, or just someone scrolling back through old mail.
SMS isn't much better, and in some ways it's worse: messages are often backed up automatically to the cloud, synced across every device signed into the same account, and stored by carriers for longer than most people assume. Slack and Teams add their own twist — searchable message history is treated as a feature, which is exactly the opposite of what you want for a one-off secret.
A disappearing chat flips all of that. The information moves once, directly between two browsers, and there's no inbox, no backup, and no search index anywhere holding onto it afterward.
What belongs in a disappearing channel
- Passwords
Handing off a login for a shared tool or a family account is the classic case — a channel with no history means the password isn't sitting in a search-able archive the moment after it's used.
- 2FA backup codes
These are meant to be used once and then forgotten. A channel that mirrors that — read once, gone — fits the nature of the codes better than an email you'll never delete.
- ID numbers
Passport numbers, tax IDs, and similar identifiers are exactly the kind of thing you don't want permanently searchable in an inbox that could be compromised years from now.
- Bank details
Account and routing numbers for a one-off transfer don't need to live forever in a message thread — they need to reach one person, once.
- Door codes and access details
A code for a lockbox, a gate, or a rental — useful for one visit and worth nothing (or worse, a security risk) if it sits in a chat log indefinitely.
The handoff flow: share, confirm receipt, let it fade
- Share the sensitive detail
Open a room, send the invite, and type the password, code, or number directly into the chat once the other person has joined. It travels straight to their browser — never through a server.
- Confirm receipt in the same chat
This is the part email can't do well: ask "did that come through okay?" or "which account is this for?" and get an answer in the same channel, instead of starting a second thread that now also needs cleaning up.
- Let the room fade
Once the handoff is confirmed, close the tab. The room expires on its own — there's no message to go back and delete, because there was never a copy sitting anywhere to begin with.
Channel comparison
| Stored on servers | Searchable later | Supports follow-up questions | |
|---|---|---|---|
| Yes, indefinitely | Yes — inbox and sent folder | Yes, but creates more permanent messages | |
| SMS | Yes — device and carrier backups | Yes, often synced to cloud | Yes, but adds to the same backed-up thread |
| Slack / Teams | Yes — workspace history | Yes, by design | Yes, but stays in a searchable channel |
| One-time note (e.g. Privnote) | Briefly, until read or expiry | No, after it's read | No — one-way, no reply possible |
| Disappearing chat (FadeChats) | Never — peer-to-peer only | No — nothing stored to search | Yes — full back-and-forth, then gone |
Feature status as of July 2026. Example values only — always verify a specific tool's current retention policy.
Keep examples fake, always
When you're testing a handoff flow or writing down an example for a teammate, never use a real credential as a placeholder — use something obviously fake, like the password correct-horse-battery-staple or a made-up account name. That habit matters more than it seems: real-looking examples get copied into docs, screenshots, and support tickets, and then quietly outlive the conversation they came from.
Frequently asked questions
Is a disappearing chat safer than emailing a password?
For a one-off handoff, yes. Email keeps a permanent, searchable copy in at least two inboxes plus backups. A disappearing chat moves the password directly between two browsers and never writes it to a server, so there's no lingering copy to later be searched, breached, or subpoenaed.
Should I split the password and the username across channels?
It's a reasonable extra precaution if you're worried about the link itself being intercepted before the intended person opens it — send the username one way and the password through the disappearing chat. For most everyday handoffs, though, the chat's one-time link and encrypted peer-to-peer transport are already the meaningful protection.
What about password managers with sharing features?
For sharing within a team you already work with, 1Password or Bitwarden's built-in sharing is the better tool — it's built for ongoing access, permissions, and revocation. A disappearing chat is for the case those tools don't cover well: a one-off, ad-hoc exchange with someone outside your organization who doesn't share your vault.
Can the FadeChats server read what I send?
No. The server only relays the connection-setup signals needed to establish the peer-to-peer link between the two browsers — it never sees message content, because that content never passes through it.