Do Encrypted Messengers Keep Logs?

Some encrypted messengers keep logs and some don't — end-to-end encryption protects the content of your messages, but it says nothing about the records a server keeps around that content. So when people ask whether encrypted messengers keep logs, the honest answer is: it depends entirely on how the service is built and what it chooses to retain. Encryption and logging are two separate questions, and a service can be strong on one while being weak on the other.

This article breaks down what "logs" actually means, how retention and time-to-live (TTL) rules work, and how to evaluate a "no-logs" claim so you can tell a real one from a marketing line.

Encryption Hides Content, Not Necessarily Logs

End-to-end encryption (E2EE) scrambles your messages so that only you and the person you're talking to can read them. The server relaying those messages sees ciphertext, not plaintext.

But a server can still record plenty of things that are not the message body:

• Who talked to whom
• When and how often
• Your IP address and rough location
• Device and app details
• Account identifiers used to sign up

None of that requires reading your messages. It's called metadata, and it can be as revealing as the content itself — sometimes more. If you want to go deeper on that idea, see our explainer on what messaging metadata is.

What Kinds of Logs Can Exist?

"Logs" is a broad word. It helps to split it into categories, because different apps handle each one differently.

Message Content vs. Metadata

In a well-designed E2EE app, message content is never stored in readable form on the server. The interesting question is what happens to the ciphertext (the encrypted blob) and the metadata attached to it. An app can encrypt content perfectly and still keep detailed metadata logs.

Account and Registration Data

This is the log that exists before you send a single message. If an app requires a phone number or email to register, that identifier is tied to your account for as long as the account exists. Even if messages are E2EE, the link between "this account" and "this phone number" is a durable record.

Connection and Delivery Logs

Servers often log connections for reliability and abuse-prevention: IP addresses, timestamps, delivery receipts, and how long a message waited to be delivered. These can be kept for seconds or for months.

How Retention and TTL Actually Work

Retention is simply how long data is kept before it's deleted. Two common models:

• Fixed retention: Data is stored for a set period (say, 30 or 90 days) and then purged. The shorter the window, the less there is to leak, subpoena, or breach.
• TTL + delete-on-delivery: A message is held only until it's delivered (or until a short maximum expires), then removed. This is the store-and-forward model most privacy-focused messengers use for offline delivery.

The key insight: data that is never collected can't be retained, breached, or handed over. An architecture that can't gather an identifier is stronger than a policy that promises not to look at one. A short TTL that deletes ciphertext after delivery beats an indefinite archive, no matter how encrypted that archive is.

How to Evaluate a "No-Logs" Claim

"No logs" is easy to say and hard to prove from the outside. Use this checklist to pressure-test any claim:

1. What's required to sign up? No phone number and no email means there's no personal identifier to log in the first place. That's the single biggest structural difference between apps.
2. What does the server actually store? Look for specifics: "encrypted ciphertext only," a stated maximum TTL, and deletion after delivery — not vague reassurance.
3. Is your network hidden? If the service can see your IP on every connection, that's a metadata log even when messages are encrypted. Onion routing (Tor) or similar can remove the IP from the picture.
4. Can the claim be verified? Open-source code and independent audits let outsiders check the design. Where those exist, they matter.
5. What's the jurisdiction and track record? Where the operator is based affects what it can be compelled to hand over — and transparency reports show what's been requested.

Read our full breakdown of what a no-logs messenger really means for the deeper version of this checklist.

How the Major Messengers Compare

Here's a fair, high-level snapshot. All claims are about default behavior; details change over time, so verify against each app's current documentation.

App	Content E2EE by default	Requires phone number	Notes on identifiers & logging
Signal	Yes	Yes	Open-source; minimizes metadata (sealed sender); usernames can hide your number from other users; adopted post-quantum key agreement (PQXDH).
WhatsApp	Yes (Signal Protocol)	Yes	Owned by Meta; collects metadata; cloud backups are not end-to-end encrypted unless you enable encrypted backups.
Telegram	No (opt-in only)	Yes	Cloud chats are not E2EE — only opt-in one-to-one "Secret Chats" are. Requires a phone number.
Session	Yes	No	No phone number; onion-routed; open-source.
Threema	Yes	No	Paid, Swiss; no phone number required; open-source clients.

A note on Wickr: the consumer app Wickr Me was discontinued by AWS at the end of 2023. AWS Wickr continues as an enterprise product.

The pattern to notice: requiring a phone number creates a durable identity log regardless of how well content is encrypted. Apps that skip that requirement have structurally less to keep.

Where Graphite Fits

Graphite is an end-to-end-encrypted messenger built to minimize what a server can log in the first place.

• No phone number, no email. Your identity is a 12-word recovery phrase generated on your device. There is no account on the server to attach an identifier to.
• A no-logs relay. The relay stores only sealed ciphertext, with a 7-day maximum TTL, deleted after delivery (ack-gated). It never sees your plaintext, your keys, or your recovery phrase.
• Your network is hidden. Graphite runs over Tor by default (fail-closed to a bundled hidden service), which hides your IP for signaling and messages. For real-time calls, the media itself is peer-to-peer (DTLS-SRTP), and on mobile calls are routed so the other person doesn't see your IP.
• Modern encryption. Messages use NaCl/libsodium X25519 sealed boxes with a hybrid post-quantum layer (ML-KEM-768) and forward secrecy via a Signal-style double ratchet.
• On-device features. AI message search runs locally — nothing is uploaded — alongside encrypted group chats, file sharing, and encrypted voice and video calls.

The point isn't a promise to behave; it's a design where there's little to log. No sign-up identifier, ciphertext-only storage with a short TTL, and an IP hidden behind Tor add up to a small footprint by construction. For the wider picture of how these pieces fit together, start with our encrypted messenger guide.

The Bottom Line

Do encrypted messengers keep logs? Some keep a lot, some keep almost none — and E2EE alone doesn't decide the answer. Look past the encryption badge to what an app requires to sign up, what its server stores, how long it keeps it, and whether your network is exposed. The strongest privacy comes from architectures that simply can't collect much in the first place.

Want to try a messenger designed around that idea? Graphite is a free public beta on Windows (portable .exe with bundled Tor), Android (sideloaded APK that works on GrapheneOS and de-Googled phones with no Google Play Services), and the web — with no phone number, no email, and no logs. Get it at graphite.chat.