“Just use Signal” is good advice, and for most people it’s the end of the conversation. But “is the message encrypted?” is the easy question. The hard question — and the one that actually determines whether a channel keeps you anonymous — is what does it leak about the fact that you’re communicating at all, and what identifier does it tie to you.
Content encryption is now table stakes; all four tools here have it. They diverge on metadata (who talked to whom, when, how often) and on identity (what you have to hand over to register). Those two axes, not the encryption itself, are what you should match against your threat model. This guide compares Signal, SimpleX, Session, and Matrix/Element on exactly those terms — and is honest about where each falls short. (For Briar, the peer-to-peer, server-less option, see our Signal vs Session vs Briar comparison.)
Before choosing an account identifier, reduce your existing digital footprint and review what is already public. For confidential source work, use the high-risk source-protection threat model to record who might observe the exchange and what exposure would mean.
Signal: The Baseline, With a Phone Number Attached
Signal is end-to-end encrypted by default for messages and calls, using the audited Signal Protocol. It’s fast, well-maintained, and the safe default for almost everyone.
Identity: Signal requires a phone number to register. You can now set a username and hide your number from contacts, but the account itself is bound to a phone number Signal knows.
Metadata: This is where Signal is genuinely strong. Its architecture is designed to retain almost nothing — when served legal demands, Signal has been able to produce essentially only the account’s creation date and last connection time. Features like sealed sender further reduce what the server can see about who is messaging whom. The unavoidable residual metadata is the phone number itself, which is a link to your real identity.
The honest limit: the phone number. If your threat model requires that no identifier connect a conversation to your real self, Signal’s registration is a problem unless you can obtain a SIM truly anonymously — which in many jurisdictions you can’t.
Best for: the overwhelming majority of people who want strong encryption and minimal metadata, where being tied to a phone number isn’t itself the threat.
SimpleX: No User Identifier At All
SimpleX Chat takes the most radical position on identity: it has no user identifiers of any kind — not a phone number, not an email, not a username, not even a random user ID. This is its central, genuinely unusual design claim.
How it works: instead of identifying users, SimpleX delivers messages through the addresses of unidirectional message queues. Each connection uses separate queues for sending and receiving, routed through relay servers that hold messages only briefly and don’t talk to each other. No server has the full picture of your contacts, and there’s no central directory of users to compromise or subpoena. Encryption uses a double-ratchet implementation providing forward secrecy, with optional post-quantum extensions in newer versions.
Metadata posture: because there’s no account and no global identifier, there’s nothing to correlate you across conversations by default — the property most messengers can’t offer. You can run your own servers, and you can route connections over Tor for IP protection.
For browsing associated with a conversation, consult the Tor Browser safety guide. Its browser setup does not configure a separate messaging app; review that app’s own routing settings too.
The honest limits: SimpleX is younger and less battle-tested than Signal, with a smaller (though growing) base of independent scrutiny. The no-identifier model has real usability costs — connecting requires exchanging an invitation link or QR code rather than looking someone up, and multi-device use is more involved. Relay operators can still observe traffic patterns at their own node even if they can’t link the whole conversation.
Best for: situations where the existence of an account tied to anything is unacceptable, and you’re willing to trade some convenience and maturity for that.
Session: No Phone Number, Onion-Routed — With a Forward-Secrecy Caveat
Session registers accounts without a phone number or email and uses an Account ID. Its FAQ describes onion routing for messages, but distinguishes peer-to-peer calls: those expose an IP address to the other participant and call infrastructure. Choose a communication mode, not just an app.
Protocol limits: At this review, Session’s FAQ describes perfect forward secrecy as planned for Protocol V2. Check current documentation for the version you use before relying on that property. Do not assume a roadmap feature already protects a conversation.
Best for: communicating without a phone number when you accept the current forward-secrecy tradeoff, and value onion-routed IP protection. Verify the protocol version’s current state before relying on it for high-stakes work.
Matrix / Element: Federated and Flexible — But Metadata-Leaky
Matrix is an open, federated protocol; Element is its best-known client. Federation is its appeal: anyone can run a homeserver, you’re not locked to one company, and it’s strong for communities, bridging, and self-hosting.
The metadata problem you must understand. Matrix encrypts message content end-to-end, but a great deal of room metadata is stored on the homeserver in plaintext as “state events.” Element’s own engineering blog is candid about this: a room’s name, topic, and other metadata sit unencrypted on the server, and room membership is visible to it. There’s also a structural concern that, because room-management events aren’t fully authenticated, a malicious homeserver could in principle add a server-controlled member to an encrypted room. Work to encrypt state events (MSC3414) is in progress and explicitly incomplete — it’s not something to count on today.
The honest limit: Matrix protects what you say far better than the social graph and structure of where you say it. For an adversary who can see or compel your homeserver, that exposed metadata can be exactly what matters.
Best for: communities, federated/self-hosted setups, and cases where rich features and openness matter more than minimizing metadata. It is not the tool to pick when hiding the existence and shape of your conversations is the priority.
The Comparison
| Signal | SimpleX | Session | Matrix / Element | |
|---|---|---|---|---|
| Identifier required | Phone number | None at all | Session ID (no phone/email) | Account on a homeserver |
| Content encryption | Signal Protocol | Double ratchet (+ PQ option) | E2EE, onion-routed | E2EE (Olm/Megolm) |
| Forward secrecy | Yes | Yes | Not currently (V2 planned) | Yes (content) |
| IP protection built in | Not established by a username | Optional via Tor | Onion-routed messages; calls differ | No |
| Metadata posture | Very little retained | No user identifier; minimal | Decentralized; no phone | Room metadata visible to server |
| Maturity / scrutiny | Highest | Newer | Moderate | Mature protocol, leaky model |
Choose a channel by the observer you need to limit
For ordinary app selection, Privacy Ranker’s Signal, Telegram, and WhatsApp comparison covers the broader product question. Here the decision is whether the account identifier, server-visible metadata, and communication mode fit your anonymity plan. Use the OPSEC mistakes checklist to review how that channel connects to your other activities.
- “I want strong encryption with minimal metadata, and a phone number is fine.” → Signal. Right for most people.
- “No identifier can exist that ties a conversation to me.” → SimpleX, accepting its relative youth and the usability cost of the no-account model.
- “I need to register without a phone number and want IP protection.” → Session, if you accept the current forward-secrecy tradeoff. Check whether Protocol V2 has shipped before trusting it for high stakes.
- “I want federation, self-hosting, or community features.” → Matrix/Element, with eyes open about server-visible metadata. Don’t use it where hiding conversation structure is the goal.
The thread tying all four together is the same one that runs through every tool we cover: encryption protects the channel, not your discipline. The most metadata-resistant messenger is undone the moment you log in with a recognizable handle, link it to an account tied to your real name, or run it on a compromised device. Pick the channel that matches your threat model — then back it with consistent operational habits, because that’s what actually keeps a conversation private.
For the device part of that review, compare Android privacy and hardening options. If the exchange also involves visiting websites, include browser fingerprinting and identity linkage in the plan and review IP-hiding options and limits separately.
For attachments, plan encrypted storage for shared files and follow the checklist for metadata removal before sending files. Record which recipients should receive each file as part of the channel decision.
