The short answer
It depends on the channel, and on what happens to the message after it arrives.
- WhatsApp and Signal encrypt messages end to end, so the service can't read them on the way. But the password then sits in the chat history on every device in the conversation, and possibly in backups.
- Email usually isn't end-to-end encrypted. It's often encrypted between servers, but each provider stores a readable copy.
- SMS isn't end-to-end encrypted at all.
For a low-stakes password, an end-to-end encrypted chat with disappearing messages turned on is reasonable. For anything that matters (banking, email, admin accounts, production systems, a password manager's master password), don't put the password itself into any chat history. Send a link that stops working once it's opened.
What each channel actually protects
| Channel | Protected in transit? | Who could read it on the way | Where copies end up |
|---|---|---|---|
| End-to-end encrypted | Not WhatsApp | Every device in the chat; cloud backups, which are end-to-end encrypted only if you turn that on | |
| Signal | End-to-end encrypted | Not Signal | Every device in the chat |
| iMessage (Apple to Apple) | End-to-end encrypted | Not Apple | Every device in the chat, and their backups |
| RCS in Google Messages | End-to-end encrypted between Google Messages users | Not Google | Every device in the chat |
| Telegram (regular and group chats) | Encrypted between each device and Telegram's servers, not end to end | Telegram's servers | Telegram's cloud, and every device you sign in on |
| SMS and MMS | Not end-to-end encrypted | Mobile carriers, and anyone with access to their networks | Both phones and carrier systems |
| Usually TLS between servers | Both email providers | Both mailboxes, sent folders, backups and archives |
The details behind that table:
- WhatsApp uses the Signal Protocol, which its technical encryption overview says is designed to prevent third parties and WhatsApp itself from having plaintext access to messages or calls. Backups are a separate matter. End-to-end encrypted backups are an option users enable; otherwise backups are secured by the cloud storage service rather than by WhatsApp's encryption (Engineering at Meta).
- iMessage encrypts messages end to end so that only the sender and receiver can read them (Apple Platform Security).
- Google Messages encrypts RCS conversations between Google Messages users by default, and states that end-to-end encryption isn't available for SMS and MMS (Google Messages Help).
- SMS: the US Cybersecurity and Infrastructure Security Agency puts it bluntly in its mobile communications guidance: SMS messages are not encrypted, and someone with access to a carrier's network who intercepts them can read them.
- Email: Gmail uses TLS to protect messages in transit when the other service supports it, and flags messages that weren't encrypted (Gmail Help). TLS protects the trip between servers; both mailboxes still hold readable copies. Stronger options such as S/MIME and client-side encryption exist, mainly for work and school accounts.
What about Telegram and work chat?
Two other places passwords often end up deserve a closer look.
- Telegram: ordinary chats, groups included, are "cloud chats" that use server-client encryption and are stored in Telegram's cloud. Only secret chats, a separate one-to-one mode, use end-to-end encryption (Telegram FAQ). A password sent in a normal Telegram chat isn't end-to-end encrypted, and it's there on every device you sign in to.
- Slack and other workplace chat: these run under your organisation's account and its settings for how long messages are kept. On Slack, workspace owners and admins can export messages from public channels on every plan, and from private channels and direct messages on some plans (Slack Help Center). Treat a password posted in work chat as visible to the people who run the workspace, for as long as the workspace keeps messages.
Encryption protects the trip, not the copies
End-to-end encryption answers one question: can someone in the middle read this? It doesn't answer the question that matters most for passwords: where does this password live from now on?
After you send a password in a chat, it typically exists:
- in the chat history on your phone and theirs, and on any linked desktop or tablet (WhatsApp supports several devices per account, each with its own keys);
- in phone and cloud backups;
- in notification previews on lock screens;
- in any screenshot either of you takes.
Each copy is somewhere the password can be found later: by someone who picks up an unlocked phone, by malware, or by anyone who gets into a backup account.
Disappearing messages reduce this, and CISA recommends enabling message expiration to delete sensitive messages automatically. But they're a tidiness feature, not a guarantee. When Signal introduced them, it said they're not for situations where your contact is your adversary, since a recipient can always photograph the screen.
A safer routine for sending a password
- Put the password in an encrypted note. Open Secure Notes and paste it. It's encrypted in your browser with AES-256-GCM before upload. Keep burn after reading on, and pick a short expiry.
- Send the link through the chat you'd normally use. The chat now holds a link, not the password. The decryption key sits after the
#in the link, and browsers don't send that part to servers (MDN). - For high-stakes passwords, split across two channels. Choose Link + password. Send the link by email or chat, and the extra password another way: a phone call, in person, or a different messaging app. Someone who gets into one account doesn't get both pieces.
- Confirm it arrived. Ask the recipient to tell you when they've read it. My links, in the browser you used, shows when it was opened.
- If it was opened before they say they opened it, treat the password as exposed and change it. A note the recipient finds already used is a warning, not a silent leak.
It works in reverse too. If you need someone to send you a password, send them a secret request: what they paste is encrypted in their browser to a key only your inbox link holds.
Splitting the link and the password
| Link goes by | Password goes by | Good for |
|---|---|---|
| Work email | A phone call | Clients and colleagues |
| Slack or Teams | A different messaging app | Teams that already use both |
| WhatsApp or Signal | Said in person | Family and household accounts |
Keep the instructions simple. Tell the recipient which message has the link and which has the password; confusion is how both end up pasted into the same thread.
When a one-time link isn't the answer
- They'll need the password again and again. Use a password manager's sharing features; see password manager vs one-time secret link.
- The service supports separate users. Inviting someone to their own account beats sharing yours.
- You suspect their phone or computer is compromised. No sharing tool fixes a compromised device.
If you already sent a password in plain text
Deleting the message helps less than it seems: the other person's devices, linked devices and backups may still have copies. If the account matters, change the password, using a password generator for the new one, and send it properly this time. If the same password is used anywhere else, change it there too, and check old passwords with a breached password checker.
Sources
- WhatsApp, WhatsApp Encryption Overview (technical white paper)
- Engineering at Meta, How WhatsApp is enabling end-to-end encrypted backups
- Apple Platform Security, iMessage security overview
- Google Messages Help, How end-to-end encryption in Google Messages provides more security
- Gmail Help, Learn how Gmail encrypts your emails
- CISA, Mobile Communications Best Practice Guidance
- Signal, Disappearing messages for Signal
- Telegram, FAQ
- Slack Help Center, Export your workspace data
- MDN, URI fragment