How End-to-End Encryption Works in WebRTC Video Calls

Quick summary: End-to-end encryption (E2EE) in WebRTC ensures that only the intended participants can access video, audio, and text data during a call – not the platform provider, not the server, and not any intermediary. It works by encrypting data on the sender's device and decrypting it only on the recipient's device. For multiparty calls routed through an SFU (Selective Forwarding Unit), technologies like Insertable Streams and SFrame make true E2EE possible without the server ever seeing unencrypted content.

As a developer of software solutions, it's important to integrate secure and reliable video conferencing into your applications. Whether you're building an event platform or a telehealth service, protecting users' privacy and ensuring secure communication should be a core requirement. This guide walks you through end-to-end encryption in WebRTC video conferencing – how it works, how it differs from other encryption methods, and how to implement it.

By understanding the advantages of E2EE, you'll be better equipped to choose and implement secure video conferencing for your clients and users.

Table of contents

1. What is end-to-end encryption?
2. How does end-to-end encryption work?
3. Differences from other types of encryption
4. What does E2EE protect the user from?
5. The benefits of end-to-end encrypted video conferencing
6. Differences between symmetric and asymmetric encryption
7. How E2EE works for conference calls in WebRTC
8. Choosing the right video conferencing API provider
9. How to enable end-to-end encryption on Digital Samba
10. Frequently asked questions
11. Conclusion

What is end-to-end encryption?

End-to-end encryption refers to a secure method of communication that encrypts data at the sender's end and decrypts it only at the recipient's end. This ensures that only the intended recipients can access the sensitive data, including the audio, video, and text messages exchanged during video conference calls.

This type of encryption provides a high level of security, because even if the message is intercepted, it will be unreadable to anyone who does not have the decryption key. End-to-end encryption is increasingly being adopted by conferencing service providers as a way to protect sensitive information and ensure user privacy.

How does end-to-end encryption (E2EE) work?

End-to-end encryption ensures the privacy and security of data exchanged between parties. Here's how it works, step by step:

Key generation

Both the sender and recipient generate a pair of encryption keys: a public key for encryption and a private key for decryption. The public keys are exchanged between the parties, while the private keys remain confidential.

Secure key exchange

To establish a secure channel, the sender and recipient use a key exchange protocol, such as Diffie-Hellman, to generate a shared secret key. This key is derived from the sender's private key and the recipient's public key (or vice versa), ensuring that only the intended parties can derive it.

Encryption

The sender uses the shared secret key to encrypt the data, including audio, video, and text messages, before transmission. This typically involves a symmetric encryption algorithm, such as AES, which provides a balance between speed and security.

Transmission

The encrypted data is transmitted over the network, safeguarded against unauthorised access and tampering. Even if an attacker intercepts the data, they cannot decrypt it without the shared secret key.

Decryption

On receiving the encrypted data, the recipient uses their private key and the sender's public key to derive the same shared secret key used for encryption, then uses it to decrypt the data and restore it to its original form.

Secure communication

Because the encryption and decryption process repeats for every message exchanged, the entire communication remains private, protected from eavesdroppers and potential attackers. By employing this process, developers can ensure that only the intended recipients can access sensitive data exchanged during video conference calls.

Differences from other types of encryption

End-to-end encryption (E2EE) provides a higher level of security than other types of encryption because the message is encrypted and decrypted only on the sender's and receiver's devices. This means that even if the communication platform is compromised, the message remains secure.

1. Compared with E2EE, Transport Layer Security (TLS) encryption, also known as server-side encryption, only encrypts data in transit between the user's device and the server. The server can therefore access the decrypted data, leaving it vulnerable to data breaches or surveillance.
2. Similarly, Secure Real-time Transport Protocol (SRTP) encryption, a commonly used protocol for real-time communication, encrypts media streams between users but not always the signalling information, such as metadata or call-setup details. This can leave SRTP vulnerable to certain attacks, such as traffic analysis.
3. In contrast, E2EE can provide forward secrecy, meaning that even if an attacker obtains a current encryption key, they cannot decrypt past communications. This adds another layer of protection for users' sensitive information.

Understanding these differences is critical when choosing a platform for GDPR-compliant video conferencing, as GDPR requires appropriate technical measures to protect personal data – and not all encryption methods provide the same level of protection.

What does E2EE protect the user from?

End-to-end encryption protects against a variety of threats, including:

Interception of messages

E2EE prevents intermediaries or third parties from intercepting or accessing the content of a video conference call. Even if an attacker intercepts the data, they cannot read it without the decryption key.

Hacking or data breaches

With E2EE, even if a communication platform experiences a data breach, the encrypted content is unreadable to any attacker without the decryption key. This protects sensitive information, such as meeting agendas or confidential topics, from being stolen or compromised.

User privacy and sensitive information

E2EE protects privacy by ensuring that only the intended recipients of a call can read its content. This matters for organisations that handle sensitive or confidential information. It also supports compliance with data-privacy regulations such as GDPR or HIPAA, which is particularly important in industries where data privacy is a top concern, such as healthcare, finance, or legal services.

Man-in-the-middle attacks

Man-in-the-middle (MITM) attacks are a common form of cyber-attack where an attacker intercepts communications between two parties, often to steal sensitive information. E2EE helps prevent MITM attacks, because encryption and decryption occur on the sender's and recipient's devices, with no intermediary able to read the content.

The benefits of end-to-end encrypted video conferencing

End-to-end encryption (E2EE) provides several benefits for conference calls in WebRTC:

• Increased security – the content of the call is only visible to the intended participants and no third party.
• Confidentiality – calls and messages remain private, which is important for sensitive discussions in healthcare, legal, or financial services.
• Compliance – E2EE supports compliance with data-privacy regulations such as HIPAA, GDPR, or PCI-DSS by protecting sensitive content from unauthorised access.
• Trust – demonstrating a commitment to privacy and security builds trust between users and service providers, which matters for organisations that rely on client trust.
• Flexibility – E2EE can be applied to various types of call, including one-on-one, group, and multiparty calls.

Differences between symmetric and asymmetric encryption

Symmetric and asymmetric encryption are two fundamental methods used in cybersecurity, and E2EE typically combines both.

1. Symmetric encryption uses a shared secret key for both encryption and decryption. Anyone who has the key can decrypt the data, which makes secure key distribution the critical challenge.
2. Asymmetric encryption, also known as public-key encryption, uses a pair of keys – a public key and a private key. The public key is freely available and can be used by anyone to encrypt data, while the private key is kept secret and used only by the recipient to decrypt it.

E2EE often combines the strengths of both. A secure key-exchange protocol like Diffie-Hellman is used to generate and share a symmetric key, and that symmetric key is then used to encrypt and decrypt the actual media, providing a balance between speed and security.

How E2EE works for conference calls in WebRTC

End-to-end encryption in WebRTC secures communication between users by combining symmetric and asymmetric encryption to create a protected environment.

During a call, WebRTC uses symmetric encryption to protect the audio and video streams. A key is generated and shared securely between the participants and used to encrypt and decrypt the media at their endpoints. When true E2EE is in place, this key is never available to the server, so only the participants can access the decrypted data.

Forward secrecy adds further protection by rotating keys, making it very difficult for an attacker to decrypt past media even if they obtain a current key.

E2EE in multiparty calls: Insertable Streams and SFrame

One of the biggest technical challenges with E2EE in WebRTC has been making it work in group calls routed through a Selective Forwarding Unit (SFU). In a standard SFU setup, the server receives media streams from each participant and forwards them to the others. With ordinary SRTP, encryption terminates at the server, meaning the SFU technically has access to the unencrypted media.

This is where Insertable Streams (formally the WebRTC Encoded Transform) and SFrame (Secure Frame) come in. Insertable Streams give developers access to encoded media frames before they're sent over the network, allowing an additional encryption layer to be applied on top of standard SRTP – so the SFU only ever sees encrypted data it cannot read.

SFrame is a lightweight framing format designed for this use case. Originally co-developed by Google (and used in Google Duo), it provides efficient per-frame encryption that works well with SFU-based architectures, and it is progressing through the IETF standardisation process. For scalable group key management, platforms increasingly pair SFrame with MLS (Messaging Layer Security, RFC 9420), which handles key distribution and rotation as participants join and leave.

Browser support note: as of early 2026, the RTCRtpScriptTransform API (the successor to the original Insertable Streams experiment) is supported in Chrome and Edge. Firefox is still implementing it, and Safari support remains limited. For cross-browser E2EE, developers should plan for graceful degradation or fallback mechanisms.

Implementation is where platforms differ. Some leave E2EE to the developer; others handle it at the platform level. Digital Samba applies E2EE at the platform level for both 1:1 and group calls, whereas many platforms either don't offer E2EE for group calls or limit it to 1:1 sessions.

E2EE also comes with trade-offs on any platform. Because the server cannot access decrypted content, server-side features that depend on it – such as server-side recording and live transcription – are not available while E2EE is on. This is inherent to true end-to-end encryption: if the server can't see the data, it can't process it. The practical point is to enable E2EE for the sessions where maximum confidentiality matters most.

Choosing the right video conferencing API provider

To integrate E2EE into your video conferencing application, it helps to choose a reliable video conferencing API provider, such as Digital Samba Embedded. Keep the following factors in mind:

1. Security features: ensure the provider supports E2EE and other essential controls like secure authentication, access control, and secure recording.
2. Scalability: choose a provider that can scale with your application's growth, handling more users and conferences without compromising performance.
3. Ease of integration: opt for a provider with a well-documented API, making it easier to integrate video conferencing features.
4. GDPR compliance: for applications serving European users, verify that the provider hosts data within the EU and offers end-to-end encryption. Safe video calls depend as much on where data is processed as on how it's encrypted.

How to enable end-to-end encryption on Digital Samba

Using the dashboard

The Digital Samba dashboard provides an interface for managing your online meetings, where E2EE can be enabled in a few clicks:

1. Navigate to the Rooms window.
2. If you're creating a new room, click 'Create a room'.
3. If you want to update an existing room, locate it within the rooms listed.
4. Scroll down to 'End-to-end encryption' and click the toggle to enable E2EE.

Using the REST API

You can also enable E2EE through the REST API. The API provides a boolean parameter, e2ee_enabled: setting it to true enables end-to-end encryption for the room. Authenticate your requests with your Digital Samba developer key, then create (POST) a new room with E2EE enabled, or update (PATCH) an existing room to toggle it.

Here is an example of creating a room with E2EE enabled, using the Digital Samba API:

curl -X POST https://api.digitalsamba.com/api/v1/rooms \
  -H "Authorization: Bearer {DEVELOPER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "friendly_url": "standup",
    "e2ee_enabled": true
  }'

Note that e2ee_enabled is set to true to enable end-to-end encryption, and that a friendly_url is auto-generated if you do not set one (here, standup is used as an example).

Frequently asked questions

Is WebRTC end-to-end encrypted by default?

Not fully. WebRTC mandates SRTP, so media is always encrypted in transit, but in a group call that encryption terminates at the SFU, which can technically access the decrypted media. True end-to-end encryption requires an additional layer, such as SFrame applied through Insertable Streams.

What is the difference between SRTP and E2EE?

SRTP encrypts media between each endpoint and the server, so the server can access the decrypted content to route or process it. E2EE keeps content encrypted from sender to recipient, so the server never sees it in plaintext.

Can group video calls be end-to-end encrypted?

Yes. Using Insertable Streams and SFrame, each participant encrypts media frames so the SFU forwards data it cannot read. Key management for larger groups is increasingly handled with MLS (RFC 9420), which rotates keys as participants join or leave.

Does E2EE work in every browser?

Not yet uniformly. The RTCRtpScriptTransform API needed for E2EE is supported in Chrome and Edge, Firefox is still implementing it, and Safari support is limited. Applications should plan for fallback where E2EE is unavailable.

What features stop working when E2EE is enabled?

Server-side features that need access to decrypted content – such as server-side recording and live transcription – are not available while E2EE is on, because the server cannot read the media.

Conclusion

For software developers, understanding end-to-end encryption and its trade-offs is essential. By integrating end-to-end encrypted video conferencing into your applications, you can protect the privacy and security of your users' communication and build trust in your product.

Demand for secure video conferencing continues to grow, driven by GDPR enforcement, the EU AI Act's governance requirements for AI systems, and rising client expectations around privacy. When choosing a provider, look for E2EE across both 1:1 and group calls, EU-hosted infrastructure, and a developer-friendly API. To go deeper, see our guide to WebRTC security fundamentals.