What Jitsi end-to-end encryption protects in a self-hosted meeting
End-to-end encryption adds a layer that the videobridge cannot decrypt, and it covers only audio, video and screen sharing in a Jitsi Meet conference. For a team that runs its own Jitsi Meet, the decision is whether meeting media should be readable by the videobridge the team operates. Without end-to-end encryption, the bridge sits inside the trust boundary of every call it routes, because it handles decrypted media while forwarding packets. With the feature enabled, the bridge forwards media it cannot read, which narrows the trust placed in the operator of the media path. The setting applies per meeting, so the team needs a written policy that says when it is used.
Teams usually consider end-to-end encryption when a meeting carries content that the platform operators should not be able to hear or see. Typical illustrative cases include a board session discussing an unannounced transaction, a clinical case review or a legal strategy call. Start by listing who has operational access to the bridge, including administrators, hosting staff and anyone who can reach the server's memory or logs. If that group is wider than the people allowed to attend the meeting, end-to-end encryption reduces the gap. Whether that reduction satisfies a specific regulatory or contractual obligation is a question for your risk owner and compliance advisers, because the setting is only one control in a larger design.
Before you commit, separate what the feature covers from what stays outside it. Jitsi's security page limits end-to-end encryption to audio, video and screen sharing and states that it does not cover chat or polls. The same page notes that a meeting password, chat and speaker stats reset once the last person leaves the room, so do not assume those items persist as a record. The default protection still applies: all Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP, and the videobridge removes that layer while routing, keeping packets only in memory and never in persistent storage. End-to-end encryption therefore sits on top of transport protection, and your documentation should describe both layers accurately.
Client support is the practical constraint. According to Jitsi, end-to-end encryption works in browsers with insertable streams support, which means Chromium 83 and later, and in the Jitsi Electron client. Participants turn it on from the Security options dialog during a meeting. Anyone joining from an unsupported browser or client cannot take part in the encrypted layer, so inventory the browsers your users actually run, test a call with mixed participants and decide what happens when someone joins from an unsupported device. Confirm current browser support with Jitsi before a rollout, because client support changes over time.
Turn the decision into a short written policy with three parts: which meeting types require encryption, who may enable it, and how participants are told that a meeting is encrypted and what remains outside the encrypted layer. Then run a test plan that checks the setting on each supported client, confirms that chat and polls behave as documented and records the results in your change file. Ask your internal team or implementation partner to document these checks next to the transport and authentication settings, so auditors and staff receive one consistent description of how meeting protection works.
Which protection mode fits each meeting type
This table compares the protection modes available on a self-hosted Jitsi deployment, from default network encryption to end-to-end encryption and mixed meetings. Read each row against the meeting type you host, then confirm feature behavior in your own test environment before you rely on it. The main takeaway is that end-to-end encryption covers audio, video and screen sharing in supported clients only.
| Mode | What the videobridge can read | Which features keep working | When it fits |
|---|---|---|---|
| Default DTLS-SRTP only | Decrypts media in memory while routing and never stores packets, per Jitsi's security page | Standard conferencing features; confirm recording, streaming and transcription in your setup | Internal meetings where bridge-side processing is acceptable under your policy |
| End-to-end encryption in supported clients | Not the content of end-to-end encrypted audio, video or screen sharing; confirm in tests | Audio, video and screen sharing only, per Jitsi; chat and polls fall outside the encryption | Meetings where every participant uses Chromium 83 or later or the Jitsi Electron client |
| Mixed meeting with unsupported clients | Confirm how the bridge handles media from participants without end-to-end encryption | Supported clients keep end-to-end encryption; confirm what unsupported clients receive | Guest-heavy meetings where encryption cannot be guaranteed for every participant |
| Chat and polls in an encrypted meeting | Confirm how chat and polls are carried, since end-to-end encryption does not cover them | Chat and polls work outside the end-to-end scope; confirm their handling in your deployment | Meetings where chat content is sensitive and needs its own control |
How Jitsi end-to-end encryption differs from DTLS-SRTP on the bridge
On a self-hosted Jitsi Meet deployment, every audio and video stream already has network encryption. Per the Jitsi security page, DTLS-SRTP protects media between each participant and the videobridge. The bridge removes that layer while it routes packets, decrypts them in memory, and never writes them to persistent storage. The default protection therefore ends at the bridge you operate. Anyone who can reach the bridge's process, memory or host during a meeting sits inside the trust boundary for media, so your plan should treat bridge hosts as sensitive systems.
End-to-end encryption adds a second layer on top of DTLS-SRTP. Participants' browsers encrypt audio, video and screen sharing before the packets leave the device, so the bridge can forward that content without needing it in readable form. The Jitsi security page limits this protection to audio, video and screen sharing and states that chat and polls are not covered. Clients need insertable streams support, which means Chromium 83 or later or the Jitsi Electron client. Participants turn the feature on from the Security options dialog, so it is a per-meeting choice. Confirm whether your deployment can require it for all meetings.
The open question is what the bridge still sees. The facts available for this topic do not describe signaling and meeting metadata in detail, and encrypting media alone does not change that data. Signaling runs through Prosody and Jicofo, so you should expect those components to handle conference setup information, such as room identifiers and participant session details. Confirm with the current Jitsi documentation which of these fields reach the videobridge, which ones it logs, and which stay in the XMPP and conference layers. Record the answer in your data flow diagram before a compliance reviewer asks for it.
Meeting state also needs planning. The Jitsi security page notes that a meeting password, along with chat and speaker stats, resets once the last person leaves the room. A password set for a recurring meeting must be reissued each time the room is recreated. Any evidence about who joined or what was shared has to come from logs that you configured and retain yourself. Decide the retention period for those logs with your legal and compliance teams, and confirm that the logging settings you choose do not capture media content.
Before you rely on the feature, run a test meeting with at least two browsers. Enable end-to-end encryption, confirm the indicator your users see, and check that a Chromium 83 or later client and the Electron client both join. Then test how a client without support is handled under your policy. Verify that chat stays outside the protection during the same meeting, and write that limit into your user guidance. Keep the test results with your security review records so the scope of the claim is documented.
Which clients support Jitsi end-to-end encryption
Jitsi end-to-end encryption depends on the browser or desktop client each participant uses, so the server setup alone does not decide coverage. The cards below cover the supported environments, what to check for anything outside them, and how to confirm the client version before a regulated meeting.
Chromium 83 and later
Browsers based on Chromium 83 or later support the insertable streams API that Jitsi uses for end-to-end encryption. Participants on these browsers can turn encryption on from the Security options dialog in a meeting. Ask every participant in a regulated meeting to join from a supported Chromium build, and confirm that the browser is kept on a supported release through your endpoint management process.
Jitsi Electron client
The Jitsi Electron desktop client also supports end-to-end encryption, so staff who prefer an installed app can use the same feature without a browser. Confirm that the client is installed from a source your organization trusts and that it is updated through your normal software process. Test the Security options dialog in the client before relying on it for a regulated meeting.
Other browsers and older Chromium builds
Browsers outside the Chromium 83 and later range should be treated as unsupported for end-to-end encryption until you test them. Older Chromium builds and non-Chromium browsers may join the meeting without the option working, which can leave participants believing a call is protected when it is not. Keep a written list of approved browsers and versions, and block or redirect older builds in your endpoint policy.
Confirming the client version
Before a regulated meeting, confirm the browser or Electron client version each participant uses, because encryption depends on the client and not only on the Jitsi server. For managed devices, read the versions from your device inventory. For guests and personal devices, define a check the host performs at the start of the meeting and record what was confirmed in your meeting log.
Turning encryption on per meeting
Encryption is switched on from the Security options dialog inside each meeting, so it is not applied automatically to every room on your deployment. Hosts in regulated workflows should include this step in their meeting runbook and confirm the setting before discussing protected information. Note that a meeting password resets when the last person leaves the room, so a new password is needed for each session.
How to turn on Jitsi end-to-end encryption in a meeting
This sequence confirms the prerequisites, enables end-to-end encryption for one meeting, and checks from a second supported client that audio, video and screen sharing are protected. Each step ends with a check so the team can tell when it is complete. The enable action applies to a single meeting, so the sequence also asks the team to agree how it will be applied consistently.
Confirm a valid HTTPS certificate on the domain
The platform owner confirms that the domain serving the meeting uses a certificate issued by a trusted authority and that the browser loads the site over HTTPS without warnings. Jitsi's handbook says a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially with mobile clients. Open the meeting URL in a clean browser session and check the certificate details for the exact domain. The step is done when the certificate is valid, matches the hostname users type, and is not self-signed. Confirm the renewal process as well, because an expired certificate will stop calls from working before it stops encryption.
Confirm each participant uses a supported client
Before the meeting, the organizer lists who will attend and confirms each person joins from a supported client. End-to-end encryption works in browsers with insertable streams support, which means Chromium 83 and later, and in the Jitsi Electron client. Participants on other browsers or older builds may not be able to use the feature. Ask each participant to report their browser version or app build, and check it against that list. The step is done when every attendee has a supported client, or when the team has decided how to handle anyone who does not. Confirm in your own deployment how a participant on an unsupported client is handled, because that behavior depends on your build and configuration.
Open the security options dialog in the meeting
The meeting host joins from a supported client and opens the Security options dialog from inside the meeting. This dialog is where Jitsi exposes the end-to-end encryption control. Open it before anyone else is relying on the meeting to be protected, because the setting is applied from within the meeting and not from the server configuration. The step is done when the dialog is open and the host can see the end-to-end encryption option. If the option is missing, check the client version first, then confirm with your build whether the control is hidden for that client, that account type or that meeting configuration.
Enable end-to-end encryption for this meeting
From the Security options dialog, the host turns on end-to-end encryption. The control applies to the meeting in progress, and the host should wait until the change is reflected in the dialog before continuing. Participants who join after the change should be able to take part in the encrypted meeting, and those already in the room should be checked as well. The step is done when the dialog shows encryption as enabled and at least one other participant confirms that they are in the same encrypted meeting. Remember that the scope is limited to audio, video and screen sharing. Chat and polls are not covered by this protection, so the host should not treat them as encrypted.
Verify protection from a second supported client
A second person joins from a different supported client, such as a Chromium-based browser and the Electron app, and checks that the meeting is encrypted from their side. The aim is to confirm that the encryption is working end to end and not only reflected in the host's dialog. The verifier checks their own Security options or the encryption indicator your build provides, then confirms that audio, video and screen sharing work between the clients. The step is done when the second client reports encryption as on and media flows normally between both clients. Record which clients and versions were tested, because the result is evidence for later review.
Agree how the team applies the setting to every meeting
The enable action is set per meeting, so a meeting that the host forgets to protect will run without end-to-end encryption. The team lead, platform owner or compliance lead writes a short procedure that says which meetings must be encrypted, who is responsible for enabling the setting, and when the check in the previous step is repeated. Consider whether the team will use calendar naming, a meeting checklist or a standard opening step for the host. The step is done when the procedure is written, the hosts know it, and a test meeting has followed it end to end. Ask your deployment owner whether any server-side option can enforce the setting for all meetings in your build, and record the answer.
Security checks before you rely on Jitsi end-to-end encryption
Jitsi end-to-end encryption protects a narrow part of a meeting, and the boundaries of that protection matter as much as the setting itself. The checks below help a security lead confirm what is covered, what is not, and which client and certificate conditions must hold before the feature is relied on for sensitive meetings.
Confirm meeting password and chat reset
Jitsi's security page notes that a meeting password, along with chat and speaker stats, resets once the last person leaves the room. Test this on your own deployment by setting a password, ending the meeting with every participant gone, and rejoining as a new participant to confirm the room is no longer locked. Record the result, because a password that persists across sessions would change how you brief hosts.
Treat chat and polls as unencrypted
Jitsi's security page limits end-to-end encryption to audio, video and screen sharing and states that it does not cover chat or polls. Any sensitive text exchanged in chat or polls is outside this layer, so decide whether those features stay enabled for regulated meetings. Write the rule into host guidance and confirm it with a test meeting that exchanges chat messages while encryption is on.
Account for unprotected speaker stats
Speaker stats are not protected by the end-to-end encryption layer, so the data they show is not covered by this control. Review which participant activity data the meeting exposes, including who spoke and for how long, against the privacy obligations that apply to your meetings. Ask the vendor or your own testing to confirm exactly what speaker stats contain in the version you deploy.
Verify the HTTPS certificate on every client
Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially with mobile clients. Check that the certificate chains to a authority trusted by your browsers, desktop clients and mobile devices, and that the domain name matches. A certificate warning on a single device type can lead users to bypass prompts, which weakens the trust model you are relying on.
Confirm client support for encryption
Jitsi end-to-end encryption works in browsers with insertable streams support, meaning Chromium 83 and later, and in the Jitsi Electron client. Participants on other browsers or clients cannot use the feature, so inventory the browsers your users run and set a policy for unsupported devices. Enable the setting from the Security options dialog and verify that every participant in a test meeting sees the encryption state you expect.
Document the default network protection
Without end-to-end encryption turned on, Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP, and the videobridge decrypts packets in memory while routing them. Your risk assessment should state that the bridge you operate can see decrypted media when end-to-end encryption is off, and that this trust sits inside your infrastructure. Confirm with your architecture team where the videobridge runs and who can access it.
Which features may stop working when the bridge cannot read media
Before you enable end-to-end encryption, apply one rule: any feature that needs a server-side component to read audio or video may stop working for encrypted meetings. This is an illustrative reasoning exercise based on how these features are built, not a limit documented by Jitsi. The features most likely to be affected are those that take a copy of the media on the server or in a separate process, such as recording through Jibri and transcription through a server-side service. Treat the rule as a list of questions to answer by testing, not as a verdict on any feature.
Jibri records or streams a conference by running Chrome in a virtual framebuffer and encoding the output with ffmpeg. Its README states that a single Jibri supports one recording at a time and should run on its own machine or VM. In practice, a Jibri instance joins the room as a participant and must receive and play the streams it captures. Whether an encrypted conference can be recorded depends on whether that participant can handle the encrypted media, and that is a question for the Jitsi handbook and the jibri repository at the version you run. Do not assume the answer from this reasoning alone, and do not promise recording to users until a test confirms it.
Transcription through Jigasi follows the same pattern. A server-side component must receive the audio in a form it can process, so encryption may block captions in the same way it may block recording. The sibling topic on meeting transcription covers backend choice and migration, so this section only flags the dependency. Decide early whether captions must work in encrypted meetings, or whether encryption will be limited to rooms where captions are not needed. Record that decision with the people who own the meeting policy, because it changes what users can expect in each room.
Build a test matrix before any live meeting. List every feature you plan to offer, such as recording, streaming, SIP dial-in, transcription, screen sharing and shared documents, and run each one in a test room with encryption turned on from the Security options dialog. Test in the browsers your users run, including Chromium 83 or later and the Jitsi Electron client, and include mobile clients if your users join from phones. The security page also says chat and polls sit outside end-to-end encryption, so test those too and tell users which parts of the meeting are protected. Record the results, the component versions and the exact steps, and repeat the matrix after every upgrade.
Limits to confirm in your environment
End-to-end encryption in Jitsi depends on the client, the message types in the meeting, the authentication method and the packaging you deploy. The cards below list what to confirm for your release, using the Jitsi security page and handbook as the source of truth for current support.
Browser and Electron versions
Jitsi states that end-to-end encryption works in Chromium 83 and later and in the Jitsi Electron client. Before rollout, confirm the exact browser and Electron versions supported for the build you run, and test them on the operating systems your staff use. Record the build number you deployed, since support can change between releases.
Chat and polls coverage
Jitsi's security page limits end-to-end encryption to audio, video and screen sharing. Chat and polls fall outside that protection. Decide how your teams will handle sensitive text during encrypted meetings, such as banning confidential content in chat or routing it through a system you control, and confirm this scope against the current vendor page.
Mixed participant behavior
Meetings often include guests on unsupported browsers, dial-in participants or people using older clients. Confirm how a meeting behaves when some participants have encryption enabled and others do not, including whether they can join, what they see and whether the meeting shows a clear indicator. Run a test call with each client type you expect to receive.
Authentication method interaction
The Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode. Confirm whether end-to-end encryption can be enabled and enforced under each method you choose, and whether guest access through a separate anonymous domain changes the result. Avoid the deprecated secure domain method for new installations.
Docker and Debian build availability
The official Docker setup runs rootless containers with read-only filesystems from stable-11146 onward, and the Debian and Ubuntu quick start covers Debian 12 and Ubuntu 24.04 or newer with OpenJDK 17. Confirm that the encryption option is present in the package or image version you deploy, and check that your upgrade path keeps it working.
Meeting password and room reset
Jitsi's security page notes that a meeting password resets once the last person leaves the room. Recurring meetings that depend on a fixed password, or on the meeting state that clears with it, need a planned process for re-entering settings. Confirm this behavior on your build and document how hosts re-enable encryption at the start of each session.
Questions buyers ask before enabling Jitsi end-to-end encryption
What makes end-to-end encryption work take longer on one Jitsi deployment?
The main drivers are how many client types you must support, which features run alongside encryption, how authentication and certificates are set up, and how much testing the change needs. Each one adds work, and timing depends on your environment, so ask for a timeline in the written scope. Client count matters because end-to-end encryption works in Chromium 83 and later and the Jitsi Electron client, so every other browser or build needs a decision. Features matter because encryption covers audio, video and screen sharing only, so chat, polls, recording and transcription each need separate planning. Authentication and certificates matter because working audio and video depend on HTTPS with a proper domain certificate, and the Jitsi handbook warns that self-signed certificates cause problems, especially on mobile clients.
Can our own team enable and test Jitsi encryption without outside help?
Sometimes, for a single deployment run by a team that already operates Jitsi, but the answer depends on your skills and on how far the change reaches. The Jitsi scalable setup guide warns that building a scalable infrastructure is not a task for beginning Jitsi administrators, so use that as a yardstick for your own team. Turning encryption on is a user-facing choice in the Security options dialog. The surrounding work includes moving authentication toward JWT tokens, testing every client and join path, and redeploying through the Docker .env file or Debian packages. If your team cannot run that cycle and roll it back safely, a partner may be the better fit. Ask for a written list of tasks split between your staff and the partner.
What must our organization provide before a Jitsi partner starts work?
Prepare a domain name you control, a certificate or a plan to obtain one, and DNS access. Provide an inventory of the browsers, Electron builds and mobile apps your users run, along with the places Jitsi will be reached from. Confirm network access for 80/TCP and 443/TCP, and 10000/UDP for media. Optionally, confirm 5349/TCP for TCP fallback and 3478/UDP for STUN. Name the operating system you will use, which the Debian and Ubuntu quick start covers with Debian 12 or newer and Ubuntu 24.04 or newer. Identify the identity source for authentication. Finally, supply a test plan with expected results, a change window and a named owner who can approve cutover.
Does encryption on Jitsi also cover chat, polls and meeting passwords?
It does not. Jitsi's security page says end-to-end encryption is limited to audio, video and screen sharing and does not cover chat or polls. The same page notes that meeting passwords, chat and speaker stats reset once the last person leaves the room, so do not treat them as lasting controls. If your policy covers messages or stored content, plan those controls separately. Put the exact scope in the written proposal, including which features your organization uses. Ask the partner to list each feature in your deployment and state whether it falls inside the encryption boundary, so testing matches what is actually protected.
How does end-to-end encryption differ from default DTLS-SRTP on Jitsi?
By default, all Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP. According to jitsi.org, the videobridge removes that layer while routing, keeps packets only in memory and never writes them to persistent storage. End-to-end encryption is an additional option for supported clients, turned on from the Security options dialog. Confirm with the Jitsi handbook and current project documentation how keys are handled and what the bridge can see when the option is on. Record that answer for your reviewers, and test the behavior end to end before you describe it in policy or to an auditor.
Which browsers and clients support encryption in Jitsi Meet?
The documented paths are Chromium 83 and later, which provides the insertable streams support the feature needs, and the Jitsi Electron client. Confirm support in Firefox, Safari and the mobile apps against current Jitsi documentation before you promise it to users. Users must turn the option on from the Security options dialog, so plan instructions and short training. Ask the partner for a test matrix listing browser versions, operating systems and client builds, with pass or fail results for audio, video and screen sharing. Keep your inventory current, because a browser update or a change in staff devices can change which meetings are covered.
Will turning on encryption make our video meetings HIPAA compliant?
No. Enabling a setting does not settle compliance for a regulated service such as telehealth. DeployOpen does not issue audit reports, attestations or certifications, since independent auditors and certification bodies do that work. DeployOpen can help prepare systems, configuration and evidence for an assessment, such as documented encryption and authentication settings, test results and change records. Ask your compliance lead which controls apply and what evidence the assessor expects. Your compliance team should map applicable requirements, including relevant control IDs from the frameworks you follow, instead of inferring them from this page. Write those evidence items into the scope before work starts.
How long will the work take, and what decides the timeline?
Timing depends on your environment, so the timeline should come from the written scope rather than a general estimate. The main factors are deployment size, the number of client types, the authentication change, certificate issuance, change windows and how much testing your organization requires. Fixed-scope engagements are agreed in writing before work starts, so the scope should state the timeline, deliverables, testing performed and the dependencies you must meet, such as certificate approval and network changes. Ask for milestones tied to your inputs, and ask what happens if the client inventory or certificate arrives late. Compare quotes on that written scope, not on headline effort.
How DeployOpen scopes Jitsi end-to-end encryption work
DeployOpen treats Jitsi end-to-end encryption as a scoped part of a self-hosted Jitsi Meet deployment inside your own infrastructure. The work starts with which clients your users run, which meetings need the protection, and what the protection will not cover, then moves through configuration, testing, documentation and handover.
How we scope
- Inventory which browsers and the Jitsi Electron client your users run, since end-to-end encryption needs Chromium 83 or later.
- Map which meeting content is in scope: audio, video and screen sharing are covered, while chat and polls are not.
- Confirm the written scope lists the meeting types, user groups and client versions that must use encryption.
How we build
- Configure the Jitsi Meet web app and clients so participants can enable encryption from the Security options dialog.
- Set up and test the authentication model alongside encryption, including JWT tokens and a separate anonymous domain for guests.
- Test end-to-end encryption against DTLS-SRTP on the videobridge, confirming which protection applies to each meeting type.
How we hand over
- Document which clients support encryption, how users turn it on, and the known limits for chat, polls and meeting passwords.
- Provide an operator runbook covering the settings, test steps and the checks to repeat after each Jitsi upgrade.
- Walk your operations and security staff through the written results and the open items agreed in the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-test encryption behavior when client versions or Jitsi Meet releases change in your environment.
- Confirm with your compliance and legal teams how encryption fits your own obligations before relying on it for regulated meetings.
