What is End to End Encryption?
Updated: 3 days ago
End to end encryption, usually shortened to E2EE, is a way of protecting digital communication so that the readable content is available only at the endpoints: the sender's device and the intended recipient's device. The service carrying the message can move the encrypted data, but a correctly designed E2EE system does not give that service the cryptographic keys needed to read the protected content.
That distinction matters. Encryption is used in many places on the internet, but not every encrypted connection is end to end. A website protected by HTTPS encrypts traffic between your browser and the website's server. With E2EE, the service itself is not supposed to be another point where the message becomes readable.
How does end to end encryption work?
At a high level, the application on the sender's device turns readable data, known as plaintext, into ciphertext before the data leaves the endpoint. The ciphertext travels through broadband networks, routers, internet exchanges, hosting infrastructure and the service provider's systems. The recipient's device uses the required cryptographic key material to turn the ciphertext back into readable content.
Modern E2EE protocols can use combinations of public key cryptography, symmetric encryption, authenticated key exchange, session keys and key rotation. It is therefore misleading to reduce every E2EE system to a single rule such as 'encrypt with the recipient's public key'. The exact mechanism depends on the protocol.
The important property is the trust boundary: the endpoints hold the information required to decrypt the content. The network in between carries encrypted data. This is different from ordinary TLS protection where a server normally terminates the encrypted connection and can then process the plaintext.
The infographic below shows the practical idea. Your device encrypts the content before transmission, the message remains unreadable while crossing the internet, and the recipient's device decrypts it.
End to end encryption vs encryption in transit
Encryption in transit protects data while it moves across a particular network connection. HTTPS is the familiar example. Your browser creates an encrypted TLS connection to a website. Anyone passively observing the broadband link should not be able to read the HTTPS payload, but the website must normally decrypt the request at its server so it can respond.
End to end encryption moves the decryption point away from the service infrastructure and onto the intended endpoint. A messaging platform can still route a message, store encrypted data or deliver notifications, but the design goal is that it cannot simply open the message content on its servers.
What can an ISP see when you use E2EE?
End to end encryption does not make internet traffic invisible. Your broadband provider still has to carry packets to their destinations. Depending on the application, network design and other privacy technologies in use, an ISP may still be able to observe destination IP addresses, connection timing, traffic volumes and other network metadata.
E2EE protects the content handled by the E2EE protocol. It is not the same thing as a VPN, and it does not automatically hide the network destination from your ISP. A VPN changes which destination your ISP directly sees by tunnelling traffic to a VPN server, while E2EE controls who can decrypt the application content.
What does end to end encryption protect?
Message content: text, images, files or call media can be encrypted so intermediaries cannot read the protected payload.
Data intercepted in transit: captured ciphertext should be unusable without the necessary cryptographic keys.
Content stored by the service: some systems store encrypted message data that the provider cannot decrypt in the normal course of operation.
Communication across untrusted networks: E2EE can protect content even when the underlying broadband, WiFi or transit network is not trusted.
What does E2EE not protect?
The phrase can sound broader than it really is. E2EE is a strong content protection mechanism, not a complete security or anonymity system.
A compromised endpoint: if malware can read the message before encryption or after decryption, the cryptography cannot make that device trustworthy.
Someone with access to an unlocked device: the authorised application may display decrypted content normally.
All metadata: who communicated, when, from which account or IP address, and how much data moved may remain visible to one or more parties.
Screenshots or forwarding: a recipient who can legitimately read content can often copy, photograph or forward it.
Unsafe backups: an application can use E2EE for live messages while backups are protected differently.
Identity mistakes: encryption is only useful if the cryptographic identity you trust really belongs to the person you intended to contact.
Keys, identity and forward secrecy
Cryptographic keys are central to E2EE, but good systems do more than create one permanent key and use it forever. Protocols can derive temporary session keys, rotate keys and delete old key material. Forward secrecy is designed to reduce the damage if a long-term key is compromised later, because possession of that key should not automatically reveal every earlier session.
Some messaging systems also provide safety numbers, security codes, QR codes or other verification mechanisms. These help users confirm that the cryptographic identity presented by the application matches the intended contact rather than an attacker inserted between them.
End to end encryption for group chats
Group communication is harder than a one-to-one conversation because membership changes. A secure group protocol has to manage who is allowed to receive new keys when somebody joins, and how access changes when somebody leaves. The IETF Messaging Layer Security architecture is one example of a modern standard designed for secure group messaging, including confidentiality and authentication properties for application messages.
Is WhatsApp, Signal or iMessage end to end encrypted?
Many well-known communication services offer E2EE for at least some forms of communication, but the precise protection can depend on the feature, device configuration, backup settings, multi-device design and whether every participant is using a compatible mode. The safest approach is to check the current documentation for the exact service and feature rather than assuming every screen in an app has identical protection.
Does E2EE slow down broadband?
For normal messaging and calling, the cryptographic processing required by modern devices is usually small compared with the time spent moving data across the network. E2EE does add computation and some protocol overhead, but it does not reduce the underlying speed of an FTTP, cable or mobile broadband connection.
If an encrypted application feels slow, the cause can still be ordinary network behaviour such as latency, packet loss, congestion, WiFi interference or an overloaded device. Encryption and broadband performance are separate parts of the system.
E2EE and public WiFi
End to end encryption is especially useful across networks you do not control because the application content remains protected beyond the local WiFi link. Even so, you should still use secure websites, keep devices updated and treat the network itself as untrusted. E2EE does not prevent a hostile network from blocking traffic, redirecting unprotected traffic or observing connection metadata.
E2EE, HTTPS and VPNs compared
E2EE: protects application content between the intended endpoints.
HTTPS/TLS: protects the connection between a client and a server, with the server normally able to read the application data.
VPN: creates an encrypted tunnel between your device or router and a VPN endpoint, changing what the local network and ISP can directly observe about destinations beyond that tunnel.
These technologies can be layered. An E2EE messaging application may use HTTPS or TLS for transport while also applying its own end to end cryptography to the message content.
UK context: privacy, safety and regulation
In the UK, end to end encryption sits within a wider debate about privacy, cyber security and online safety. The UK Government has stated that it supports strong encryption while also arguing that online services need effective child-safety measures. The Online Safety Act created duties for regulated services and gives Ofcom the role of enforcing the UK's online safety regime.
For broadband users, the technical point remains separate from the policy debate: strong E2EE is specifically designed so that intermediaries carrying or hosting protected communications do not possess routine access to the plaintext content.
Common misconceptions about end to end encryption
E2EE means nobody can ever see the message
No. The sender and intended recipient can see it, and anyone who compromises or gains access to either endpoint may be able to see it too.
E2EE hides who I am talking to
Not necessarily. Content encryption and metadata protection are different problems. A service may still need account, delivery and timing information to operate.
HTTPS is automatically end to end encryption
Not in the usual E2EE sense. HTTPS protects the browser-to-server connection, but the web server normally decrypts the traffic.
A VPN gives every app E2EE
No. A VPN encrypts traffic to the VPN endpoint. Applications still need their own E2EE protocol if the service provider itself should be unable to read the protected content.
How can you tell whether a service really uses E2EE?
Look for documentation that explains where encryption and decryption occur, how keys are established, whether the provider can access message content, how new devices are authorised, what happens to backups, and whether users can verify contact identities. A simple padlock icon or the phrase 'encrypted' is not enough to prove end to end protection.
End to end encryption FAQs
What does E2EE stand for?
E2EE stands for end to end encryption.
Can my broadband provider read E2EE messages?
A correctly implemented E2EE protocol is designed to prevent the broadband provider from reading the protected message content. The provider can still carry the traffic and may observe network metadata.
Can the app provider read end to end encrypted messages?
The defining design goal is that the provider does not hold the keys required to decrypt the protected content in the normal communication path. Implementation details, backups and endpoint access still matter.
Is end to end encryption the same as encryption?
No. Encryption is the broader process of transforming readable data into a protected form. E2EE describes an architecture in which encryption remains effective between the communicating endpoints rather than terminating at an intermediary service.
Does E2EE make me anonymous?
No. It can protect content without hiding account identity, IP addresses, traffic timing or other metadata.
The key takeaway
End to end encryption is about where readable data is allowed to exist. Instead of trusting every network and server between two people, the cryptographic trust boundary is pushed to the endpoints. That can provide powerful privacy and security for message content, but it does not secure a compromised device, hide all metadata or replace HTTPS, VPNs and good security practice.
To explore the related technical concepts used in this End to End Encryption guide, visit our broadband terminology guide.
