Jitsi Meet desktop app for Windows, macOS and Linux

Choose the client you need

The desktop application is Jitsi Meet Electron. It is separate from the Android and iPhone app, the browser meeting page and the server hosting a meeting. Start with the organizer’s full HTTPS invitation and intended server, whether you use a browser or an installed client. [S1]

For a quick browser join, use the meeting-entry guide. Installing another client does not supply a missing host, moderator password, recording service or permission to enter a meeting.

Client choice also does not remove the provider’s meeting policy. For the public service, read the meet.jit.si time-limit guide; distinguish that service from your organization’s own server.

Download from the official project

Use the official desktop releases or a distribution route linked by the project’s installation instructions. The reviewed release lists these choices: [S1][S2]

Choose for your actual OS and architecture. Files such as .blockmap and latest.yml are update metadata, not the application to launch. Follow your organization’s installation policy and platform verification checks; do not substitute an unrelated download mirror because a security prompt appears.

We verified the published asset names and documented routes, not installer execution, publisher-signature behavior or compatibility with every OS release.

Check updates separately from the server

Record the installed client’s version using its version display or package metadata. Compare it with the release you intend to use. After your normal approved update, close and reopen the application and confirm the version again; downloading an installer alone does not establish that the running client changed.

The reviewed 2026.10.0, published 21 October, updates its bundled Electron runtime to 43.8.3. The Jitsi release specifically connects this to the October certificate-trust response involving an eMudhra hierarchy. Google’s separate advisory explains the browser/root-store response and potential certificate-chain compatibility changes. This is a reason to evaluate the documented client update, not evidence that jitsi.help or your meeting server was attacked. [S2][S3]

Updating Chrome, an OS package or the Jitsi server is not a substitute for confirming this desktop build’s installed version. If a server then fails certificate verification, have its operator check the actual chain. Do not disable verification or bypass a certificate warning to make the meeting open.

Use your organization’s default server

Release 2026.10.0 lists the default-server change. Its pinned launcher recognizes the argument --defaultServer in either form below. These are arguments for the installed application, not commands for a downloaded installer: [S2][S4]

--defaultServer=https://meet.example.com

--defaultServer https://meet.example.com

Replace the example with the approved server origin and add the argument through the launcher appropriate to your installed client. Use an origin here, not a private invitation, JWT or password. This setting does not provision a server, authenticate an account or override room admission.

The source also supports JITSI_DEFAULT_SERVER and explicitly notes development-launch argument handling. That is developer configuration, not a requirement for ordinary app users. We reviewed the parser and renderer handoff but did not launch the app to verify persistence or platform-specific shortcut behavior. [S4]

A meeting opens, but login is lost

If the organizer’s link works in a browser but fails when the desktop meeting window opens, record both the client version and where the failure occurs. The release lists PR #1162, which preserves the meeting object’s query/hash information during the handoff rather than allowing recent-list processing to mutate it. [S2][S5]

That correction is a specific released change, not proof that every JWT, SSO or lobby failure has the same cause. After an approved client update, retest the organizer’s intended flow. If it still fails, have the operator check JWT expiry, claims and server policy separately. Never post the complete invitation, token or private room identifier to demonstrate the error.

Verify the result with a small test meeting

1. Confirm the installed application version and intended HTTPS server.
2. Join a disposable meeting using the organizer’s supported flow.
3. Verify admission, camera and microphone with another participant.
4. Check screen sharing and any desktop-specific feature you rely on separately.
5. Record a sanitized symptom and version if the browser and desktop client differ.

Use camera/microphone diagnostics or screen-share diagnostics for those paths. A loaded window, the existence of an auto-update feature or a successful server homepage request does not establish a complete working meeting.

Scope and sources

Reviewed 25 October 2026 against the official release, pinned README and launcher source. No desktop executable was downloaded or run, and no installation, login, media, certificate or OS matrix test was completed. This is source-reviewed guidance; recheck releases before changing the recommendation.

• [S1] Pinned desktop README and installation routes.
• [S2] Jitsi Meet Electron 2026.10.0 release, published 21 October 2026; release metadata and asset names checked 25 October.
• [S3] Google’s certificate-trust advisory, 20 October 2026. This is certificate context, not a diagnosis of a particular Jitsi installation.
• [S4] Pinned launcher and default-server parsing and merged default-server PR #1164.
• [S5] Merged JWT handoff correction #1162, included in the reviewed release.