Reviews
Signal, WhatsApp, Matrix and iMessage compared: encryption, backups and metadata defaults
Signal, WhatsApp, Matrix and iMessage compared on content encryption, backups and metadata defaults, and what to confirm on your own account.
What to take away
- Ask three questions of each messengerwho can read content by default, where the history is backed up, and what the service still records.
- Signal and WhatsApp both use end-to-end encryption by default for chats and calls, with the Signal Protocol.
- The backup is where they differWhatsApp cloud backups are encrypted only when the user turns on encrypted backup.
- Matrix depends on the client and the room, so check the room, not only the app.
- iMessage is end-to-end encrypted between Apple devices, and SMS fallback is not covered.
- Vendor defaults change, so confirm each setting on your own account.
A messenger's own label says little about the part you actually use. What matters is the default content protection, the backup posture and what the service records anyway. The table sets four widely used messengers side by side, and the sections after it show where each row can mislead.
Four messengers by default
| Messenger or protocol | Content protection by default | Backup posture | Metadata posture |
|---|---|---|---|
| Signal | End-to-end encryption by default for chats and calls, using the Signal Protocol | Device-local; no server copy of message content | Sealed sender reduces what the service sees |
| End-to-end encryption by default for chats and calls, using the Signal Protocol | Cloud backups are encrypted only when the user turns on encrypted backup | The service keeps account, delivery, and group data | |
| Matrix | Olm and Megolm encryption; default depends on the client and room | Optional server-side key backup with a recovery key or passphrase | Homeserver operators see membership and timing |
| iMessage | End-to-end encryption between Apple devices; SMS fallback is not covered | Messages in iCloud follow the account data protection setting | Apple sees routing and account data |
Vendor defaults change, so confirm the setting on your own account before you rely on a row.
Read the columns before the rows
Each column answers a different question. Content protection says who holds the keys. Backup posture says where history sits after delivery. Metadata posture says what the service records whatever the encryption.
Protections and what they do not promise
Protection
- Transport encryption
- One hop
- End-to-end encryption
- Participant endpoints
- Disappearing message
- Client history
- Encrypted backup
- Stored history
- Metadata
- Routing and identifiers
Control point
- Transport encryption
- Client and server
- End-to-end encryption
- Participant devices
- Disappearing message
- App settings
- Encrypted backup
- Recovery key holder
- Metadata
- Service dependent
Does not promise
- Transport encryption
- Post-hop safety
- End-to-end encryption
- Hidden metadata
- Disappearing message
- No screenshots
- Encrypted backup
- Live-delivery protection
- Metadata
- Content secrecy
End-to-end encryption is designed so defined sender and recipient endpoints hold the keys needed to read message content. The details depend on the protocol, device enrollment, group changes, verification and backup design, which is why the same label can mean different things in different apps.
Signal: the history stays on the device
Signal uses end-to-end encryption by default for chats and calls. Its backup posture is device-local, with no server copy of message content, and sealed sender reduces what the service sees.
That leaves the phones themselves. Even in a protected conversation, a recipient's phone can display, copy, notify, back up or share the content. Malware or physical access at an endpoint can bypass protection in transit.
CISA's mobile communications guidance was crafted partly in response to threat actors seeking to compromise end-to-end encrypted communications.
WhatsApp: encrypted chats, optional encrypted backups
WhatsApp shares Signal's default for content, so the difference is the backup. Cloud backups are encrypted only when the user turns on encrypted backup, which makes that single setting the one to confirm.
Ask whether the backup is encrypted, whether it is end-to-end encrypted, who holds recovery keys, what content it includes, and how deletion or account recovery affects it. The service keeps account, delivery and group data in any case.
Stronger key control can reduce provider access and also reduce provider-assisted recovery. Store recovery contacts or keys according to the platform's supported process.
Matrix: the client and the room decide
Matrix uses Olm and Megolm encryption, and the default depends on the client and the room. One room can be encrypted while another in the same account is not, so the app name alone settles nothing.
Key backup is optional and server-side, protected by a recovery key or passphrase. Homeserver operators see membership and timing. Ask where encryption terminates and who can decrypt stored content before you treat a room as private.
iMessage and the SMS fallback
iMessage is end-to-end encrypted between Apple devices. When a conversation falls back to SMS, that protection does not apply, and the lock-style indicators no longer describe the message.
Messages in iCloud follow the account data protection setting. Apple's iCloud data security overview distinguishes standard data protection from Advanced Data Protection and lists different key arrangements across services, including iCloud Mail, iCloud Backup and Messages in iCloud. It does not describe Android, a third-party messenger, or the recipient's separate backup.
Google's explanation of end-to-end encryption in Google Messages makes the same point for its own product. It limits the feature to eligible RCS conversations between supported Google Messages users, so SMS and unsupported RCS are not covered by that page's end-to-end protection. Neither page carries a version number, so check the page's own update stamp against your app version and region.
Transport encryption sits under all four
Transport Layer Security can protect a connection against network eavesdropping and tampering. NIST describes TLS as providing mechanisms to protect data during electronic dissemination across the Internet. A receiving provider can still process and store the message.
For a messaging app, a protected client-server connection does not by itself mean the provider lacks content keys. That is why a secure-connection padlock is not evidence for any row in the table.
Timers and metadata cut across every row
A disappearing timer tells supported clients when to remove content from ordinary history. Timer start, linked-device delivery, quoted content, media saving, reports and backups can affect what remains. A camera pointed at the screen defeats any app-level timer without breaking encryption.
Metadata can include account identifiers, phone numbers, email addresses, IP addresses, delivery time, group membership, device registration, attachment size and routing. Which fields exist depends on the service. Service logs can retain them after the app deletes the chat.
Metadata also sits beside other data classes, such as sensitive and inferred data. Avoid absolute claims unless the provider's current protocol documentation supports the exact field and mode.
What a screen can prove about a row
Each piece of evidence supports a narrow claim and no more. Read across before you repeat what a product says about itself, and treat anything in the last column as unproven.
| Evidence | Claim it can support | Claim it cannot support alone |
|---|---|---|
| Lock icon in documented eligible chat | That mode was indicated for that conversation | Recipient identity, safe device, no backup |
| TLS connection | That network leg was encrypted | End-to-end secrecy |
| Timer setting | Client removal was configured | No screenshot or report |
| Backup setting | A stated backup mode was enabled | Every included record or recipient copy |
| Deleted chat | Local or provider action occurred | Erasure from all devices and archives |
How the layers combine
How the layers combine
- Transport encryption protects client-to-server email traffic
- Message-level encryption protects email beyond server hops
- End-to-end messaging coexists with unencrypted notification previews
- Disappearing chats can still enter encrypted backups
- Encrypted backups outlive messages that disappeared live
- Providers without content keys still use metadata
The layers fail one at a time. A chat can be end-to-end encrypted and still be screenshotted. A backup can be encrypted with keys the provider holds. A timer can clear one copy while another remains.
Strongest by scope: end-to-end encryption for content in transit, and a user-keyed encrypted backup for stored history. Weakest: metadata, which no layer here removes.
Common questions
Can encrypted backups be recovered by the provider?
It depends on who holds keys and the service's recovery design. Read the current documentation for the chosen mode.
Why do Signal and WhatsApp differ on backups?
Both encrypt content end to end by default. Signal's backup posture is device-local, while WhatsApp cloud backups are encrypted only when the user turns on encrypted backup.
Do disappearing messages hide metadata?
No. The timer governs content only.
Does a lock icon prove the recipient is the intended person?
No. Verify the account, device and participant identity through an appropriate trusted route, and keep the account and recovery settings under control.
