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 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
- Join a test meeting on the intended server with consenting participants and harmless content. Use the same clients you plan to use later.
- 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]
- 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]
- 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.
- 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]
- 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 or a bridge failure after a third join. [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 and captions 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 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, 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, participant capability checks, conference support handling and English warnings.
- [S3] Jitsi’s explanation of E2EE trust pitfalls, checked 26 October 2026; architectural context, not a test of this deployment.
- [S4] Official E2EE introduction, 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.