# Jitsi Meet end-to-end encryption: what it protects

> Jitsi encrypts meeting media in transit. Optional end-to-end encryption adds protection for audio, video and screen sharing across the media router; it does not extend that protection to chat or polls. Use the meeting's available Security options, check every participant's client support and verify the state after people join. A supported browser for ordinary meetings is not automatically proof of E2EE compatibility. [S1][S2]

Source: https://jitsi.help/guides/jitsi-end-to-end-encryption/
Updated: October 26, 2026
Publisher: Jitsi Help (https://jitsi.help/)

## Transport encryption and optional E2EE

Jitsi's official security guidance distinguishes network protection from optional media end-to-end encryption. In a bridged meeting, the ordinary DTLS-SRTP layer terminates at the videobridge. With the additional media E2EE layer, the media router cannot read the protected audio/video payload. This is not a claim that every meeting feature is covered. [S1]

| Protection | What it addresses | What it does not establish |
| --- | --- | --- |
| HTTPS and media transport encryption | Network transport protection. [S1] | That optional media E2EE is enabled |
| Optional media E2EE | Audio, video and screen-sharing payload protection across the router. [S1][S4] | E2EE protection for chat or polls |
| Login, lobby and room password | Admission and organizer access rules | That an admitted participant or their endpoint is trustworthy |

Keep the [meeting's access policy](/guides/jitsi-login-moderator-password/) in place. Encryption does not decide who should be invited or who should be a moderator.

## Before relying on it

This guide checks the web controls and warnings against **Meet 11248**, immutable commit `f765042b`, on 26 October 2026. The reviewed UI calls the feature experimental and warns that people without support may not see or hear encrypted media. It also warns about server-provided services such as phone participation. These warnings deserve a rehearsal on the actual deployment. [S2]

Record the meeting server, each intended browser/app and its version. Ask the operator whether the feature is available on that deployment. A current Chromium browser or the Jitsi Electron desktop client is a documented starting point, but do not turn an old minimum-browser-version statement into a guarantee about today's client or another platform. Native apps, Safari-based clients, custom SDKs and embedded meetings need their own compatibility check. [S1][S2]

Decide whether phone participants, recording, streaming or captions are required. Do not assume those services can use the protected media just because they work in an ordinary meeting. Arrange an explicit feature test with the operator before a sensitive session; this review does not establish a supported combination for every service. [S2]

## Enable and verify on a disposable meeting

1. Join a test meeting on the intended server with consenting participants and harmless content. Use the same clients you plan to use later.
2. Open the meeting's overflow menu and its **Security options**, where the official guidance places the optional encryption control. In the reviewed web component the switch is labeled **Enable End-to-End Encryption**. Follow the prompts in your actual client. [S1][S2]
3. Read every capability or conference-size warning before relying on the setting. The source checks whether the conference supports E2EE and tracks participants without support; merely seeing a switch is not a complete compatibility result. [S2]
4. Coordinate with the other participants and inspect their actual encryption status. Verify two-way audio, video and any intended screen share. Do not assume a local toggle alone confirms the state of everyone else.
5. Have another intended client join, then recheck status and media. The reviewed source includes warnings about large-participant modes, including a warning that additional joins can change availability. Do not assume the initial state will remain unchanged as the group grows. [S2]
6. Repeat any required phone, caption or recording workflow separately. Agree in advance what to do if an essential client or service cannot participate; do not silently change the protection expected by the group.

These are recommended acceptance checks, not an independently completed encrypted meeting, security audit or device matrix from this site.

## Missing switch, black media or a changing status

**The control is missing:** ask the operator about the deployed client and configuration, and record your exact browser/app version. Ordinary meeting support and optional E2EE support are different questions. Installing another app without checking its capabilities does not settle the issue. [S2]

**One person loses media after enabling it:** inspect the client-support warning and compare that participant's exact client. The reviewed warning explicitly describes participants without support losing access to audio/video. Distinguish this from a general [device-permission problem](/troubleshooting/jitsi-camera-microphone-not-working/) or a [bridge failure after a third join](/troubleshooting/jitsi-video-not-working-3-participants/). [S2]

**The setting becomes unavailable as people join:** inspect the large-conference warning. The reviewed E2EE component chooses different descriptions and switch availability for its large-participant modes. This article does not promise one universal participant limit across versions and deployments. [S2]

**A recording or transcription workflow no longer works:** ask the operator to verify the complete media/service path. A server-side service's availability before encryption was enabled is not evidence that it can consume encrypted content. See the separate [recording](/guides/jitsi-recording-jibri/) and [captions](/guides/jitsi-captions-languages-translation/) owners for their normal prerequisites. [S2]

For Docker and Debian/Ubuntu users, there is no new server-install command in this participant checklist. Identify the runtime configuration and matching client release before changing settings. The [hardening guide](/guides/jitsi-security-hardening/) covers the separate server-administration work.

## What E2EE cannot promise

Jitsi's own discussion of E2EE points out an important trust boundary: the service delivering the client and the components routing media are not the same part of the system. Protection against a compromised media router does not automatically remove the need to trust the client software or whoever delivers it. A malicious or compromised endpoint is a different threat. [S3]

Treat admitted participants, their devices and any copies they make as part of your meeting's trust decision. Keep invitations private, authenticate intended attendees where needed and choose a recording/retention policy the group understands. This guide provides no guarantee of anonymity, regulatory compliance or prevention of participant recording. [S3]

## Sources and maintenance

- **[S1]** [Official Jitsi security and privacy explanation](https://jitsi.org/security/), checked 26 October 2026. Browser capability claims are assessed separately from dated minimum-version examples.
- **[S2]** Meet 11248 immutable source: [E2EE switch and large-mode descriptions](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/e2ee/components/E2EESection.tsx), [participant capability checks](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/e2ee/functions.ts), [conference support handling](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/e2ee/middleware.ts) and [English warnings](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/lang/main.json).
- **[S3]** [Jitsi's explanation of E2EE trust pitfalls](https://jitsi.org/e2ee-whitepaper/e2ee-pitfalls/), checked 26 October 2026; architectural context, not a test of this deployment.
- **[S4]** [Official E2EE introduction](https://jitsi.org/blog/e2ee/), published 12 April 2020. Used for the media-layer scope and design background, not its historical UI screenshots or a current compatibility matrix.

Recheck capabilities, warnings and service compatibility when changing the client, server or expected meeting size. No Jitsi meeting, cryptographic implementation audit, server change, phone or screen-reader test was performed for this article.

## Frequently asked questions

### Is every part of a Jitsi meeting end-to-end encrypted?

No. Optional media E2EE covers audio, video and screen sharing, not chat or polls. Transport encryption, access control and optional media E2EE are different protections.

### Can I assume every browser or mobile app supports Jitsi E2EE?

No. Check the exact client, version, deployment and capability warnings. Being able to join an ordinary meeting does not establish support for the optional encrypted-media path.

### Why is the E2EE switch unavailable?

Check deployment settings, client support, the other participants and any large-meeting warning. The reviewed client includes participant-capability checks and a mode that can restrict the E2EE switch as the conference grows.

### Does E2EE stop another participant recording the meeting?

Do not rely on it for that purpose. A participant's endpoint must receive usable media for them to take part. E2EE is not a permission system that prevents that participant from making a copy.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.