encrypting message content is a solved problem. the real fight is metadata: who talks to whom, when, how often, from where. a court order that returns "these two accounts exchanged 400 messages the week before the leak" needs no content at all. judge a messenger on three things: what its servers can know, what identifier it forces you to have, and who holds the keys. the logo is the last thing that matters.
every choice below is a trade between three axes. identifier, whether the service forces a phone number, an email, a username, or nothing at all. metadata exposure, whether a server (or your isp) can see the social graph and timing even when it can't read content. trust and jurisdiction, who runs the infrastructure, under which country's subpoena power, and whether the code is open and audited. content encryption is table stakes now. almost everything here has it. the differences that matter are on the other two axes. work out your threat model first, then read this as a menu, not a leaderboard.
signal know the trade centralized · e2ee default
the boring right answer, and the one to move your actual contacts to. the double-ratchet signal protocol encrypts everything by default, and the server is engineered to hold almost nothing. the handful of grand-jury subpoenas signal has answered returned only an account-creation timestamp and a last-connection date. sealed sender hides the "from" field from signal's own servers, private contact discovery keeps your address book from being uploaded in the clear, and usernames (2024) let you be reached without exposing your phone number. it was last audited by trail of bits in 2025. the honest caveats: registration still requires a phone number, the servers are centralized and sit under us jurisdiction, and metadata protection depends on features you should verify are on. turn on disappearing messages and registration lock, and compare safety numbers with the two or three contacts where compromise would actually hurt.
molly recommended signal network · android
signal for people who worry about the phone itself being seized. a hardened android fork that encrypts the local message database behind a passphrase, wipes secrets from ram when locked, can route through tor, blocks unknown senders more aggressively, and ships reproducible builds so you can verify the binary matches the source. it speaks to the same signal network, so you keep the same reach. two flavors exist, one that uses google services and a fully independent one for degoogled phones.
simplex chat recommended no identifiers · relays
the only messenger with no user identifiers of any kind: no phone, no email, no username, not even a random account number. instead of a directory, each contact is a pair of one-way encrypted message queues on relay servers, established from a link or qr you share out of band. the practical consequence is that a server never holds a social graph to hand over, only transient queues it can't correlate, and you can run your own relays to remove even that trust. it adds quantum-resistant key exchange, an incognito mode that gives each contact a different random profile, and hidden profiles behind a passcode. audited by trail of bits in 2022 and again in 2024. the cost is real and worth stating. it is the youngest ecosystem here, groups and multi-device are less polished than signal, and managing connection links by hand is more work. the strongest metadata story on this page for anyone willing to pay in convenience.
briar recommended p2p over tor · offline mesh
designed for the day the network is against you. there are no central servers. you add a contact by scanning a qr in person or exchanging a link, and from then on messages sync directly. online, that sync runs over tor hidden services, so your ip is never exposed to your contact or to an intermediary. offline, when the internet is throttled or cut, briar carries messages over bluetooth and local wi-fi, which is exactly why it shows up at protests and during shutdowns. everything is stored encrypted on the device and nowhere else. the trade is inherent to a serverless design. delivery generally wants both parties online at some point, or a trusted contact's "mailbox" to hold messages in between. android-first. a desktop client exists and is younger.
cwtch niche p2p over tor · groups
from open privacy, and the answer to "i want briar's metadata resistance but for group chat." conversations run peer-to-peer over tor onion services. optional untrusted servers can host groups and hold messages for offline delivery without being able to read who is talking to whom or what they say. the userbase is small by design and the polish reflects that. the pick for the genuinely metadata-obsessed who need more than one-to-one.
tox know the trade p2p · dht
serverless and fully distributed over a dht, with solid nacl-based content encryption. the catch is structural and cannot be fixed by settings. because peers connect directly, your ip address is visible to your contacts and, to a degree, to the dht, and online status leaks. there is no robust offline messaging, and development is spread across independent clients (qtox and others) of uneven quality and audit coverage. a genuinely interesting protocol. the wrong tool if network-level anonymity is the point.
jami know the trade p2p · dht
from savoir-faire linux, a gnu project. distributed over a dht with no account server, strong at encrypted audio and video calls, sip-compatible. it carries the same caveat as tox. the peer-to-peer model exposes network metadata, including ip, to the people you talk to. a good fit for private calls between people who already trust each other's network position, less so for anonymous text.
matrix / element know the trade federated · self-hostable
encryption on by default in private rooms, self-hostable, and excellent for durable community coordination. the trade is metadata. room membership, timing, and who-is-in-what live on every homeserver that participates in a conversation, and cross-signing and key management add operational complexity. choose your homeserver the way you would choose a landlord, or run your own to control where that metadata sits. strong for groups, weak as an anonymity tool.
xmpp + omemo know the trade federated · open standard
the veteran open standard. omemo provides double-ratchet end-to-end encryption, but only when both clients support and enable it, and metadata sits on the servers regardless. its strength is that you can fully self-host and it will outlive any single company. fine for a community server you control. not designed to hide the social graph.
whatsapp avoid for privacy centralized · meta
content is end-to-end encrypted with the signal protocol underneath, and that part is real. everything around it is the problem, and all of it is verifiable. whatsapp's own privacy policy describes what it collects and shares with the meta companies: phone number, contacts when granted, device identifiers, usage, connection and location signals. the 2021 policy change formalized business-data flows to meta, and propublica's investigation the same year detailed how "end-to-end encrypted" coexists with review of reported messages and heavy metadata exploitation. chat backups to icloud or google drive are only end-to-end encrypted if you switch it on yourself, and most people never do, quietly handing their history to a cloud provider. on a privacy wiki the verdict is simple. the metadata, who you talk to, when and how often, is the product, and meta is the buyer. move contacts to signal. if someone cannot be moved, treat whatsapp as monitored and keep anything sensitive off it.
telegram avoid for privacy cloud-stored
the reputation and the reality diverge sharply. ordinary chats and every group and channel are not end-to-end encrypted. they sit on telegram's servers, readable by telegram. "secret chats" are end-to-end encrypted but are opt-in, limited to one-to-one, and absent from the desktop client, so most conversations never use them. and since late 2024, telegram's stated policy is to disclose phone numbers and ip addresses in response to valid legal requests. treat it as a social network with a chat interface and post accordingly.
session winding down onion-routed
worth knowing why it is greyed out. session dropped phone numbers and routed messages over the oxen service-node network, identifying users by a persistent 66-character account id. in april 2026 the session technology foundation announced it would wind down operations that july, citing roughly a million dollars a year needed to finish its protocol v2. do not start new conversations on a messenger that is losing its maintainers. existing users should migrate to simplex or briar depending on threat model.
the app is a small part of the picture, and a few habits decide the rest. the full discipline is in the opsec guide. the messenger-specific pieces:
.:: eof ::.