What Is End-to-End Encryption in Video Calls?

End-to-end encryption in video calls means your audio and video are encrypted on your device and decrypted only on the devices of the people you are talking to. Servers in the middle forward data they cannot read. Most group video calls use transport encryption instead, where the server decrypts every frame it relays.

That distinction is the whole story, and it is the reason two platforms can both show you a padlock icon while offering very different levels of privacy. One is protecting your call from the network. The other is protecting your call from everyone, including the company running the service. If you are choosing a tool for patient consultations, legal advice, HR conversations or cross-border deal-making, knowing which one you have is not a technicality — it is the difference between a private conversation and a conversation someone else could theoretically replay.

Table of Contents

• How End-to-End Encryption Works on a Video Call
• Transport Encryption vs End-to-End Encryption
• Why Most Group Calls Stop Short of E2EE
• The Standards Behind Encrypted Video: SFrame and MLS
• What End-to-End Encryption Does Not Protect
• The Trade-Off Nobody Advertises
• How to Verify an Encryption Claim
• Which Level of Protection Does Your Meeting Need?
• Frequently Asked Questions

How End-to-End Encryption Works on a Video Call

Every video call turns your camera and microphone input into a stream of encoded frames. Encryption decides who holds the keys to unlock those frames.

In an end-to-end encrypted call, the participants' devices generate and hold the keys. Your device encrypts each frame before it leaves, and only another participant's device has the material needed to decrypt it. Anything between the two — your router, your internet provider, the media server, the data centre it sits in — handles ciphertext. If an operator copied the traffic, they would get noise.

The hard part is not the encryption itself. It is key management: agreeing on a shared secret between people who have never exchanged keys before, and rotating that secret every time someone joins or leaves so a latecomer cannot decrypt the first ten minutes they missed. That problem is why genuine end-to-end encryption took so long to arrive in group video, long after it became standard in messaging apps.

Transport Encryption vs End-to-End Encryption

Both are real encryption. They differ in who can take the lock off.

Transport encryption is not a weak consolation prize. WebRTC, the standard that powers browser-based calling, makes it mandatory: media travels over SRTP with keys that DTLS negotiates, and the spec simply forbids sending unencrypted media. Any browser call you join is encrypted on the wire whether or not the provider markets it.

What transport encryption does not do is exclude the provider. The server decrypts, processes and re-encrypts. That is a deliberate design choice, not a flaw — but you should know it is the design you are using.

Why Most Group Calls Stop Short of E2EE

A two-person call can connect directly, peer to peer, with nothing in the middle. Add a third participant and that stops scaling: every person would have to upload a separate copy of their video to everybody else.

So group platforms use a Selective Forwarding Unit (SFU) — a media server that receives one stream from each participant and forwards the right copies to everyone else, adapting quality to each connection. It is the reason a twelve-person call does not melt your laptop.

The catch is structural. The SFU performs its own handshake with each participant, so it holds the transport keys. It decrypts each incoming frame and re-encrypts it on the way out. At that moment your media exists in plaintext in the server's memory. Germany's federal cybersecurity agency, the BSI, made exactly this point in its minimum standard for video conferencing services (version 1.0, 7 October 2021): a conference server or MCU breaks the encryption open at that point. The same document warns that many services running on the provider's own servers are described as end-to-end encrypted, and that such claims should be critically questioned, because the provider may still know the key.

Regulators have tested that warning in practice. In November 2020 the US Federal Trade Commission announced a settlement with Zoom over allegations that, since at least 2016, the company had advertised "end-to-end, 256-bit encryption" while retaining cryptographic keys that could let it access meeting content, and had stored some recordings unencrypted on its servers for up to 60 days. The FTC finalised the order on 19 January 2021, requiring a comprehensive security program and prohibiting security misrepresentations. The company later shipped genuine end-to-end encryption as an opt-in mode. The lesson for buyers is durable: the phrase on the pricing page is a marketing claim until you can trace it to a documented key model.

The Standards Behind Encrypted Video: SFrame and MLS

Real E2EE over an SFU became practical once the industry solved two separate problems with two open standards.

The first is encrypting the media so the server can still do its job. RFC 9605, published in August 2024, defines Secure Frame (SFrame): lightweight authenticated encryption for real-time media that lets a central media server read the metadata it needs for forwarding decisions without ever accessing the media itself. The sender encrypts each frame; the SFU routes ciphertext; the receiver decrypts. Browsers expose the hook for this through the WebRTC Encoded Transform API, and MDN lists <code>RTCRtpScriptTransform</code> as Baseline since October 2025 — which is to say the browser plumbing only became broadly dependable very recently.

The second problem is distributing and rotating keys among a changing group. RFC 9420, the Messaging Layer Security (MLS) protocol published in 2023, provides asynchronous group key exchange with forward secrecy and post-compromise security for groups from two to thousands of members. In plain terms: someone who joins at minute 20 cannot decrypt minute 5, and someone who leaves cannot decrypt what is said after they go.

When a vendor tells you it offers end-to-end encryption, these are the names you want to hear. A provider that cannot tell you how it generates keys, where they live and when they rotate is describing a wish, not an architecture.

What End-to-End Encryption Does Not Protect

E2EE is narrow by design. It protects call content in transit between endpoints, and nothing else.

Metadata stays visible. Who joined, from which account and IP address, when the meeting started, how long it lasted, how much data moved. The service has to know this to route the call. Metadata alone can be revealing: a pattern of calls between a law firm and a company at 2 a.m. tells a story without a single decrypted word.

Endpoints are fair game. If a participant's laptop has malware or their screen faces an open-plan office, encryption in the middle is irrelevant. The weakest device in the call sets the real security level.

Participants can still capture the call. Anyone in the meeting can run screen-recording software or point a phone at the monitor. The BSI minimum standard explicitly requires organisations to tell users that other participants can make screenshots and recordings unnoticed, even when the built-in recording function is off.

Recordings live outside the encrypted session. The moment a call is recorded and stored, its protection depends on encryption at rest, access controls and retention policy — a different problem entirely. GDPR Article 32 lists the encryption of personal data as an appropriate technical measure alongside the ongoing confidentiality, integrity and availability of processing systems — so a recording sitting unencrypted in cloud storage undermines the very compliance case the encrypted call was meant to support.

That gap is not hypothetical. IBM's Cost of a Data Breach Report 2026, based on 602 organisations breached between March 2025 and February 2026, puts the global average breach at $4.99 million and found that only 37% of breached organisations encrypted sensitive data both at rest and in transit, while just 34% had visibility into their cryptographic assets. Breaches that involved AI-enabled attacks cost around $6 million, roughly $1 million above the global average.

The Trade-Off Nobody Advertises

Here is the part most explainers skip. If the server genuinely cannot read your media, the server cannot do anything useful with it either.

Turn on true end-to-end encryption and you typically lose cloud recording, server-side live captions, transcription, meeting summaries and real-time translation — not because vendors are withholding features, but because every one of those features requires a process somewhere to listen to decrypted audio. Platforms that offer E2EE as a mode generally disable those capabilities while it is active, and say so in the interface.

This matters most for multilingual meetings. Live AI translation works by taking audio, converting it to text, translating it and delivering it back as captions or synthesised speech within a second or two. That pipeline has to process audio in the clear at the point of translation. Any platform claiming both strict end-to-end encryption and server-side live translation in the same session is describing something that does not hold together.

The honest position is to state which model you are running and what happens to the audio. Meeyra is browser-based and built on WebRTC, so meeting media is encrypted in transit on every plan, with no app install and no plugin. When you switch live translation on, the platform processes audio in real time to produce the translation and keeps nothing afterwards — the trade-off is made explicitly rather than hidden behind a padlock icon. For calls where server-side processing is unacceptable, the right answer is a dedicated E2EE mode with captions and recording switched off, on any platform that offers one.

How to Verify an Encryption Claim

Treat the marketing page as a hypothesis and test it:

1. Ask who holds the keys. The only answer that qualifies as end-to-end encryption is "the participants' devices, and never our servers." Anything softer is transport encryption.
2. Look for the standards. SFrame (RFC 9605), MLS (RFC 9420), DTLS-SRTP. A vendor doing real E2EE will name them; a vendor doing transport encryption should say so plainly.
3. Check what breaks when E2EE is on. If recording, captions and transcription keep working in an allegedly end-to-end encrypted session, the server is reading your media.
4. Read the qualifier. Phrases like "encrypted end to end during transmission" describe transport encryption. That is fine — it is the accuracy of the label that matters.
5. Ask where the media servers are. For GDPR purposes, data location and the processor agreement often matter more than the cipher suite. Our guide to GDPR-compliant video conferencing covers what to require in writing.
6. Ignore the padlock. As the BSI notes, many systems display a lock symbol that says nothing about the quality of the encryption behind it.
7. Check the retention policy. Ask how long recordings, transcripts and logs are kept, and who can access them.

Which Level of Protection Does Your Meeting Need?

Most organisations do not need maximum encryption on every call. They need the right level per scenario, documented.

If your calls cross borders and languages, the practical priority is usually a documented data path rather than the strongest possible cipher — see our comparison of the most secure video conferencing platforms for how vendors differ on data location and certifications, and the step-by-step guide to starting an encrypted video call when you want to put this into practice today.

Frequently Asked Questions

Is every video call end-to-end encrypted?

No. Almost every browser-based video call is encrypted in transit using DTLS-SRTP, which is mandatory in WebRTC, but that is not the same as end-to-end encryption. True E2EE, where the provider cannot decrypt your media, remains an optional mode on most platforms and rarely covers large meetings.

What is the difference between end-to-end encryption and encryption in transit?

Encryption in transit protects data between your device and the server, and the server can decrypt it. End-to-end encryption keeps the keys on participants' devices, so the server forwards data it cannot read. The gap between them is the provider's own access.

Can an end-to-end encrypted video call still be recorded?

Yes. Any participant can record locally with screen-capture software or simply film the screen. E2EE prevents the server from reading the stream; it cannot stop a person in the meeting from keeping a copy.

Does end-to-end encryption hide who I called?

No. Metadata such as participant identities, IP addresses, meeting start time and duration remains visible to the service, because it is needed to route the call. E2EE protects content, not the fact that a conversation happened.

Why do captions and live translation stop working with E2EE?

Because both features need a process to read decrypted audio. When the server only ever sees ciphertext, there is nothing for speech recognition or translation to work on, so platforms disable server-side captions, transcription and translation while end-to-end encryption is active.

Does GDPR require end-to-end encryption for video meetings?

No. GDPR Article 32 names encryption as an appropriate technical measure but does not mandate a specific method; the requirement is that measures are appropriate to the risk. For sensitive categories such as health data, regulators expect stronger safeguards, documented data locations and a processor agreement.

How can I tell if my provider's E2EE claim is genuine?

Ask who holds the keys, which standards the platform implements (SFrame, MLS), and which features stop working once E2EE is on. If recording and transcription keep working, the server can read your media. A padlock icon on its own proves nothing.

Is browser-based video calling less secure than a desktop app?

Not inherently. Browser calls run on WebRTC, where encrypted media is mandatory and the browser enforces HTTPS and explicit camera and microphone permissions. Skipping an install also removes a class of risk, since there is no additional software to keep patched on every device.

Encryption is only worth as much as the claim behind it is precise. A provider that tells you exactly where your media is decrypted, how long anything is kept and which features would break under stricter encryption is giving you something you can actually assess. One that offers only a padlock and the phrase "end-to-end" is asking for trust it has not documented.

If you want calls that are encrypted in transit, run in the browser without an install, and can bridge 42+ languages in real time with a translation data path you can explain to your compliance team, create a free Meeyra room and test the encryption questions in this article against it — then ask the same questions of every other tool on your shortlist.