Which messenger should I use?¶

There is no universal “most secure messenger”. The right starting point depends on your devices, what you protect and your adversary.

Report 1.0 · 14 October 2026. No network lab, controlled forensic testing or bit-for-bit reproduction of binaries. Unknown remains Unknown.

Compare the main messengers¶

Open a row to see properties and limits. Descriptions are qualitative; no grade is calculated.

SignalMature content security, adoption and iPhone + PC usability.Limit: Mandatory number known to the provider and telecom layer.

Security / E2EE: Mature E2EE for messages and calls; endpoint security remains crucial. [1] [2]
Privacy / metadata: Service knows the number; some account dates were publicly disclosed. [1] [2]
Pseudonymity / identity: Registration phone number; optional username. [1] [2]
Network anonymity: No general resistance to a global passive observer is demonstrated. [1] [2]
Ease of use: Very practical for iPhone + PC; the primary phone remains necessary. [1] [2] [3] [4]
iOS: Yes, client listed in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Yes, client listed in the study. [1] [2]
macOS: Yes, client listed in the study. [1] [2]
Linux: Yes, client listed in the study. [1] [2]
Main strength: Mature content security, adoption and iPhone + PC usability. [1] [2]
Main weakness: Mandatory number known to the provider and telecom layer. [1] [2]
Best suited for: Everyday security; peer-facing pseudonymity with hardened settings. [1] [2] [3] [4]
Confidence and scope: Scope-limited documentary evidence; production metadata and distributed binaries not experimentally verified. [1]

Read profile · Compare

SimpleXRelationship separation without a mandatory global identifier.Limit: More multi-device friction; relays and notifications require care.

Security / E2EE: Double Ratchet E2EE; message padding is declared. [1] [2]
Privacy / metadata: No global account; relays, queues, timing and iOS push remain exposure surfaces. [1] [2]
Pseudonymity / identity: Local profile; relationship-specific invitations. [1] [2]
Network anonymity: No general resistance to a global passive observer is demonstrated. [1] [2]
Ease of use: More setup and friction than Signal; local pairing. [1] [2] [3] [4]
iOS: Yes, client listed in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Beta; desktop-specific limits. [1] [2]
macOS: Beta; desktop-specific limits. [1] [2]
Linux: Beta; desktop-specific limits. [1] [2]
Main strength: Relationship separation without a mandatory global identifier. [1] [2]
Main weakness: More multi-device friction; relays and notifications require care. [1] [2]
Best suited for: Pseudonymous online contacts; minimising account identifiers. [1] [2] [3] [4]
Confidence and scope: Scope-limited documentary evidence; production metadata and distributed binaries not experimentally verified. [1]

Read profile · Compare

OlvidNo mandatory number; documented TURN-only calls.Limit: No network anonymity; calls and multi-device require a licence.

Security / E2EE: Formally studied protocol under limited assumptions; not an audit of the entire 2026 system. [1] [2]
Privacy / metadata: Routing keys, sizes and timing visible in the formal model. [1] [2]
Pseudonymity / identity: Cryptographic identity; no mandatory phone or email. [1] [2]
Network anonymity: No general resistance to a global passive observer is demonstrated. [1] [2]
Ease of use: Cross-platform; licensing and old history are concrete constraints. [1] [2] [3] [4]
iOS: Yes, client listed in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Yes, client listed in the study. [1] [2]
macOS: Yes, client listed in the study. [1] [2]
Linux: Yes, client listed in the study. [1] [2]
Main strength: No mandatory number; documented TURN-only calls. [1] [2]
Main weakness: No network anonymity; calls and multi-device require a licence. [1] [2]
Best suited for: Avoid sharing a number with the contact; verify cryptographic identity. [1] [2] [3] [4]
Confidence and scope: Scope-limited documentary evidence; production metadata and distributed binaries not experimentally verified. [1]

Read profile · Compare

SessionPhone-free identity and onion routing for messages.Limit: Protocol V1 attacks and unknown fix / retest status; calls expose IP.

Security / E2EE: Protocol V1: WOOT 2026 findings; current fixes and retests not established. [1] [2]
Privacy / metadata: Nodes and relays see their portion of traffic; calls expose IP. [1] [2]
Pseudonymity / identity: Random ID without a phone number; onion routing for messages. [1] [2]
Network anonymity: No general resistance to a global passive observer is demonstrated. [1] [2]
Ease of use: Cross-platform; security limitations are separate from usability. [1] [2] [3] [4]
iOS: Yes, client listed in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Yes, client listed in the study. [1] [2]
macOS: Yes, client listed in the study. [1] [2]
Linux: Yes, client listed in the study. [1] [2]
Main strength: Phone-free identity and onion routing for messages. [1] [2]
Main weakness: Protocol V1 attacks and unknown fix / retest status; calls expose IP. [1] [2]
Best suited for: Candidate for reassessment after documented fixes and retesting; not a high-assurance starting point. [1] [2] [3] [4]
Confidence and scope: High assurance not established: distributed fixes and post-WOOT 2026 retests remain unknown. [1] [2]

Read profile · Compare

ThreemaID without mandatory phone or email; mobile maturity.Limit: Desktop beta limits, account data and linkable purchases.

Security / E2EE: E2EE; properties depend on the client, particularly desktop beta. [1] [2]
Privacy / metadata: ID, connection data and optional identifiers; store purchase may link identities. [1] [2]
Pseudonymity / identity: Random Threema ID; optional phone and email. [1] [2]
Network anonymity: No general resistance to a global passive observer is demonstrated. [1] [2]
Ease of use: Established mobile client; desktop experience remains beta and limited. [1] [2] [3] [4]
iOS: Yes, client listed in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Beta; desktop-specific limits. [1] [2]
macOS: Beta; desktop-specific limits. [1] [2]
Linux: Beta; desktop-specific limits. [1] [2]
Main strength: ID without mandatory phone or email; mobile maturity. [1] [2]
Main weakness: Desktop beta limits, account data and linkable purchases. [1] [2]
Best suited for: Peer-facing pseudonymity without a mandatory number. [1] [2] [3] [4]
Confidence and scope: Client-specific properties; no PFS in Desktop 2.0 beta, retest status needs verification. [1] [2]

Read profile · Compare

CwtchOnion architecture without a single central account server.Limit: No iOS; niche ecosystem and more limited assurance.

Security / E2EE: E2EE through onion services according to published design. [1] [2]
Privacy / metadata: Reduced central concentration; presence and traffic correlation remain possible. [1] [2]
Pseudonymity / identity: Local / onion profile; no phone or email required. [1] [2]
Network anonymity: Tor reduces some local visibility; no general resistance to global correlation. [1] [2]
Ease of use: Specialised tool; setup and adoption are less straightforward. [1] [2] [3] [4]
iOS: No official client established in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Yes, client listed in the study. [1] [2]
macOS: Yes, client listed in the study. [1] [2]
Linux: Yes, client listed in the study. [1] [2]
Main strength: Onion architecture without a single central account server. [1] [2]
Main weakness: No iOS; niche ecosystem and more limited assurance. [1] [2]
Best suited for: Users on supported platforms who accept Tor and a specialised tool. [1] [2] [3] [4]
Confidence and scope: More limited current assurance and audits; Tor does not establish global resistance. [1] [2]

Read profile · Compare

BriarAndroid resilience without Internet, Tor and proximity exchange.Limit: No iOS or calls; essential maintenance since July 2026.

Security / E2EE: E2EE; Tor and local Android transports. [1] [2]
Privacy / metadata: Less centralisation; local / Tor network and endpoints remain observable. [1] [2]
Pseudonymity / identity: Local identity; contacts in person or through invitation. [1] [2]
Network anonymity: Tor / local: useful against some observers; no global guarantee. [1] [2]
Ease of use: Specialised use; usability, power and feature limits. [1] [2] [3] [4]
iOS: No official client established in the study. [1] [2]
Android: Yes, client listed in the study. [1]
Windows: Beta; desktop-specific limits. [1] [2]
macOS: Beta; desktop-specific limits. [1] [2]
Linux: Beta; desktop-specific limits. [1] [2]
Main strength: Android resilience without Internet, Tor and proximity exchange. [1] [2]
Main weakness: No iOS or calls; essential maintenance since July 2026. [1] [2]
Best suited for: Two Android contacts when offline resilience matters. [1] [2] [3] [4]
Confidence and scope: Scope-limited audits; essential maintenance only since July 2026 and a separate beta desktop client. [1] [2]

Read profile · Compare

Understand before choosing¶

End-to-end encryption — E2EE

Participants’ devices control content keys. The transport server should not read ordinary messages. Learn more

Metadata

Data around the exchange: accounts, IP, timing, volume, devices or groups. Learn more

Pseudonymity

Use an identity different from your civil identity. It can still be linked to you. Learn more

Network anonymity

Reduce the ability to link traffic to your network address or its destination. Learn more

Choose a reading path¶

A recommendation (2–5 minutes): Quick guide → Decision guide
Understand privacy (10–20 minutes): Learn the concepts → Common misconceptions
Compare two applications: Compare messengers → General comparison
OPSEC and pseudonymous contacts: OPSEC → By use case
Verify the research: Methodology → Audits