End-to-end encryption vs encryption in transit

Published 2026-10-24

Almost every app says it is encrypted, but the word covers very different protections. Some stop a stranger on the café Wi-Fi from reading your messages. Fewer stop the company running the service from reading them. This article separates encryption in transit from end-to-end encryption, explains where WebRTC calls fit, and gives you questions to ask about any messenger.

Encryption is about who holds the key

Encryption turns readable data into scrambled data that only someone with the right key can turn back. The useful question is therefore not whether something is encrypted but who holds the key at each step. If the key is at the two ends of a conversation and nowhere else, nobody in the middle can read it. If a middle party holds a key, that party can read the data, even if everything on the wire between you and it is scrambled.

Encryption in transit: protecting the road

Encryption in transit protects data as it travels between two points, for example between your browser and a website. On the web this is Transport Layer Security, TLS, which is what the padlock and the letters https stand for. MDN lists three things TLS provides. Encryption: the data exchanged between client and server is encrypted while in transit, so attackers cannot read it. Integrity: an attacker cannot secretly modify the data in transit without being detected. Authentication: the client and server can each prove they are who they claim to be, although on the web it is usually only the server that proves itself.

That is a large benefit. HTTPS is the defence against a person in the middle who sits between your browser and the server and tries to read or change the traffic. It is a main reason why using an app over public Wi-Fi is less risky than sending data unprotected.

What it does not do is protect the content from the service at the other end of the connection. TLS ends at the server, where the data is decrypted so that the service can process it. The service can then store it, scan it, show it to its staff or hand it to authorities, subject to its own rules and the law. Encryption in transit says nothing about any of that; it only says the road was safe.

End-to-end encryption: protecting the content

End-to-end encryption, E2EE, is different. The Electronic Frontier Foundation defines it as a message that is encrypted by its sender and can only be decoded by its final recipient. Other forms of encryption, it explains, may depend on encryption performed by third parties, and that means those parties have to be trusted with the original data. E2EE reduces the number of parties who might be able to interfere with or break the encryption.

In an E2EE messenger the keys live on the devices of the people talking. The server carries scrambled data and cannot read it, even if it wants to or is forced to. This is a strong property, and it comes with trade-offs. Features that need the server to read content, such as server-side search, spam filtering, or recovering history for a new device, are harder. If you lose all your devices and keys, nobody can recover your messages.

E2EE also does not hide everything. Metadata, such as who talks to whom, when and how often, is often visible to the service. Messages can still be copied by the person who receives them, screenshotted, or read on an unlocked phone. And E2EE protects content only if you are talking to the right person, which is why some messengers let you compare a safety code.

Where WebRTC calls fit

Browser calls use a technology called WebRTC. The WebRTC security architecture (RFC 8827) makes encryption mandatory for the media: all media channels must be secured with SRTP and all data channels with DTLS. In a call that runs directly between two browsers, that encryption is negotiated between the two browsers, and the audio and video travel from one to the other without being decrypted along the way, which behaves like end-to-end encryption for that stream.

Two caveats apply. First, a call is set up by a signalling service that passes connection details between the browsers, and the standard warns that this service could, in principle, mount a man-in-the-middle attack unless the users compare key fingerprints through a separate channel. Few apps ask users to do that. Second, a call that has to go through a relay server is still encrypted on the path, but a relay is one more party that carries the traffic. In short, encrypted WebRTC media between two browsers is a good start but it is not, on its own, a full promise about the whole service, and it says nothing about text messages, which a service may send in another way.

Three common situations, compared

A message sent through a server that you reach over HTTPS: encrypted on the road; the service can read it.
A message sent with E2EE: encrypted on the road and unreadable by the service; the keys are on the devices.
A WebRTC call directly between two browsers: the media is encrypted between the two ends; the setup passes through a signalling service.
A group message that goes via a server: encrypted on the road; whether the service can read it depends on whether the app uses E2EE for groups.
A file sent through a cloud link: encrypted on the road; stored by the provider, who can usually read it unless you encrypted it yourself first.

Questions to ask about any messenger

Does the app use end-to-end encryption by default, for every kind of message, including groups, files and calls? Or only in an optional mode?
Who holds the keys? If the service can reset your keys or restore history without your devices, it holds some of the power.
What does the service store, and for how long? Messages waiting for an offline user, backups and logs are often stored.
Is the code or at least the design documented and independently reviewed?
What metadata does the service collect?
Does the privacy policy say plainly what the service can and cannot read?

Be wary of vague phrases such as bank-level security or military-grade encryption, which describe the strength of an algorithm, not who holds the key. A trustworthy service says in plain words what it can see.

Choosing the right tool

Use a messenger with default end-to-end encryption for sensitive conversations such as health, money, legal matters and anything you would not want a company or a hacker to read. For everyday coordination, a service that encrypts in transit and says plainly what it stores can be enough, provided you treat it as non-confidential. Whatever you use, keep your device locked, update it, and be careful about what you forward.

About ChatLite

ChatLite is explicit about where it stands: traffic is encrypted in transit, direct WebRTC connections are encrypted between browsers, and some messages and files pass through its server, which can technically read what it relays, because ChatLite does not currently provide application-level end-to-end encryption. The Your data page lists exactly what is stored where.

References

Official documentation used to check this article. Pages are maintained by their owners and may change.

Reviewed against ChatLite's current behavior on 2026-10-24.