Jitsi Meet Web Frontend: Architecture and Customization Guide

Overview

If you have ever opened a Jitsi call in your browser and wondered what is happening behind that clean screen, you are in the right place. The Jitsi Meet web frontend is the part of Jitsi that you see and touch: the video tiles, the toolbar, the chat panel, the settings menu, and the join screen. It is an open-source app that you can read, change, and host on your own server.

Many teams start with a basic Jitsi install and later want to change the logo, hide a button, or embed the meeting inside their own website. That is when it helps to know how the frontend is built. In this guide, I will walk you through the architecture in plain words, then show the different ways to customize it, from the easy ones to the deeper ones.

What Is the Jitsi Meet Web Frontend?

Jitsi is not one program. It is a group of parts that work together. The frontend is the web app that runs in the user’s browser. The other parts run on your server and handle things like signaling and video routing.

The main pieces look like this:

• Jitsi Meet (the web app): the user interface you see in the browser.
• lib-jitsi-meet: a JavaScript library that talks to the server and handles the WebRTC connection.
• Jicofo: a server component that manages conference rooms and decides who joins what.
• Jitsi Videobridge (JVB): the server that receives and forwards audio and video.
• Prosody: the XMPP server that carries signaling messages between the browser and the backend.

When someone types a room name into the browser, the web app loads, connects to Prosody through lib-jitsi-meet, and Jicofo places the person in the right room. After that, the video and audio flow through the Videobridge.

The good news is that the frontend and backend are fairly separate. You can change how the app looks and behaves without touching the video servers in most cases.

The Core Architecture in Simple Terms

Let me break the frontend into layers. This makes it much easier to know where to look when you want to change something.

Layer 1: The React and Redux App

The Jitsi Meet web frontend is built with React for the interface and Redux for keeping track of the app’s state. If you have used React before, the structure will feel familiar.

Redux holds the current state of the meeting. For example, it knows who is in the room, who is muted, which layout is active, and whether the chat is open. When something changes, the state updates and the screen updates with it.

The code is organized by feature. Inside the project you will find a features folder, and each feature (such as the toolbox, chat, filmstrip, or recording) usually has its own components, actions, reducers, and middleware. This feature-based layout is one of the best things about the project. If you want to change the chat, you look in the chat folder. You do not have to hunt through the whole codebase.

Over the last few years, the project has also been moving many files from plain JavaScript to TypeScript. So depending on the version you download, you may see a mix of both. This is worth knowing before you start reading the code.

Layer 2: lib-jitsi-meet

Think of lib-jitsi-meet as the engine under the hood. The React app does not talk to WebRTC or the XMPP server directly. It asks lib-jitsi-meet to do that work.

This library handles:

• Connecting to the XMPP server
• Creating and joining a conference
• Getting the camera and microphone
• Sending and receiving audio and video tracks
• Sending events back to the UI (someone joined, someone left, someone started talking)

Because it is a separate library, other apps can use it too. If you only need the engine and want to build a completely different interface, you can use lib-jitsi-meet on its own. This is a bigger job, but some teams choose it when they want full control.

Layer 3: Config Files and Static Assets

The third layer is the set of files that tell the app how to behave and what to show. The two you will meet most often are:

• config.js: controls behavior, such as default settings, features, and server details.
• interface_config.js: controls some interface options, such as which toolbar buttons appear and which text is shown. Note that the Jitsi team has been slowly moving many of these settings into config.js, so check the current docs for your version.

Next to these, you have the CSS and SCSS files, images, language files, and small HTML snippets that the app loads. These are the easiest places to make changes.

How the Pieces Connect

Here is the flow in short:

• The browser loads the web app from your server.
• The app reads config.js to learn how to behave.
• React renders the join screen.
• When the user joins, the app calls lib-jitsi-meet.
• lib-jitsi-meet connects to Prosody and Jicofo, then sets up media with the Videobridge.
• Events from the library update Redux, and React redraws the screen.

Once you see this loop, the whole project makes more sense.

Ways to Customize Jitsi Meet

There is no single right way to customize Jitsi. The best choice depends on how much you want to change and how much maintenance you can handle. Here are the main options, from lightest to heaviest.

Option 1: Edit config.js and interface settings

This is the fastest and safest route. On a standard Debian or Ubuntu install, the config file usually lives on the server in a folder like /etc/jitsi/meet/, and it is named after your domain.

With config changes alone you can:

• Start calls with the camera or microphone off
• Set a default language
• Turn features on or off (for example, the lobby, recording, or live streaming buttons)
• Choose which toolbar buttons show up
• Change video quality settings

A small example is the toolbar. If you do not want people to see certain buttons, you can list only the ones you want to keep. This alone solves a lot of “please hide that button” requests.

The best part is that these changes usually survive updates better than code changes do, though you should still keep a backup of your file before every upgrade.

Option 2: Change the Look with CSS, Images, and Text

If you want custom branding, this is your next step. You can replace the logo, change the background on the welcome page, and update colors and fonts.

Common changes include:

• Swapping the watermark and logo images
• Changing the welcome page title and description
• Editing colors and spacing with custom CSS
• Updating text in the language files

Be careful here. If you edit the files that ship inside the package, an update might overwrite them. A safer habit is to keep your custom files in a separate place and copy them in after each update, or better, script the process so you never forget.

Also check the license and brand rules before you use any Jitsi or 8x8 logos in your own product. The code is open source under the Apache 2.0 license, but you should still read the terms about names and trademarks.

Option 3: Embed Jitsi with the IFrame API

Sometimes you do not want to change Jitsi at all. You just want it to live inside your own site or app. The Jitsi Meet IFrame API is built for this.

With it, you add a small script to your page, and Jitsi loads inside a frame. Then you can control it from your own code. For example, you can:

• Set the room name and the user’s display name
• Choose which buttons appear
• Listen for events, like someone joining or the call ending
• Send commands, like muting the microphone or starting a recording

This is a great fit for online classes, telehealth tools, support portals, and booking apps. Your team gets a working video room without maintaining a forked copy of the frontend.

Option 4: Build from Source and Modify the Code

This is the deepest level. You clone the jitsi-meet repository, install the dependencies, make your changes, and build your own version of the web app.

You would do this if you want to:

• Add a brand new button or panel
• Change how the filmstrip or layout works
• Add your own login step or custom flow
• Fix a bug or test a new idea

The general steps look like this:

• Clone the jitsi-meet repository from GitHub.
• Install the Node.js dependencies with npm.
• Run the build with the project’s make command or its development server.
• Point the dev server at a working Jitsi backend so you can test with real calls.
• Build a production version and deploy it over your existing web files.

Always check the README in the repository for the exact commands and the required Node.js version, because they change over time.

Building from source gives you the most freedom, but it also gives you the most work. Every time Jitsi releases an update, you will need to merge your changes with the new code. If you make many changes, this can get painful fast.

Option 5: Use lib-jitsi-meet for a Fully Custom Interface

If even the frontend is too limiting, you can skip it and build your own interface on top of lib-jitsi-meet. This is the right choice when your product has a unique design, such as a virtual event platform or a game-like meeting room.

The tradeoff is clear. You get total control of the experience, but you now own everything: the layout, device selection, permissions, error handling, and mobile behavior. It is not a small project.

Comparison: Which Customization Method Should You Pick?

My honest advice: start at the top of this table and move down only when you have to. Most teams never need to go past the IFrame API.

Tips for a Smooth Customization Process

A few habits will save you a lot of stress.

Keep changes small and documented. Write down every file you touch and why. When you upgrade in six months, you will thank yourself.

Use version control. Even for config and CSS files, keep them in Git. It takes five minutes to set up and can save hours later.

Test on a staging server first. Do not experiment on the server your users depend on. A second small server, or even a local setup, is enough.

Test on real devices. A change that looks great on your laptop may break on a phone. Jitsi is used a lot on mobile browsers, so check Chrome, Safari, and Firefox at a minimum.

Watch the browser console. When something breaks after a change, the console often tells you exactly what went wrong.

Read the release notes before updating. Jitsi moves quickly. Settings get renamed, moved, or removed. A quick read of the release notes can prevent a broken meeting page.

Keep security in mind. If you add custom scripts or change authentication, remember that video calls carry private conversations. Use HTTPS, keep your server packages current, and consider using JWT authentication if you do not want strangers creating rooms on your server.

Common Problems and How to Avoid Them

Here are a few issues that come up again and again.

Your changes disappear after an update. This happens when you edit files inside the packaged folders. Keep a backup and a small script that reapplies your changes.

The toolbar setting does nothing. Some options moved from interface_config.js to config.js in newer versions. Check the docs for your specific version.

The IFrame will not load. Check that your domain is correct, that you are using HTTPS, and that the browser is not blocking camera or microphone permissions inside the frame. You may need to set the right allow attribute on the iframe.

The build fails. This is usually a Node.js version issue. Match the version that the repository asks for.

The call works for two people but breaks for more. This is often a server or network issue, such as UDP port 10000 being blocked, and not a frontend problem. Do not start rewriting the frontend before you check the server.

Is Customizing Jitsi Worth It?

For most people, yes. Jitsi gives you a real video platform with no per-user license fees, and you keep control of your data if you host it yourself. Customization lets you make it feel like your own product instead of a generic tool.

But be honest about your team’s skills and time. Small branding and config changes are easy for almost anyone who is comfortable with a Linux server. Code-level changes need someone who knows React, Redux, and WebRTC basics. If you do not have that person, the IFrame API is a very good middle path.

Conclusion

The Jitsi Meet web frontend looks simple on the surface, but it is a clean, well-organized system. React and Redux run the interface, lib-jitsi-meet manages the connection, and a few config files decide how everything behaves. Once you understand those three layers, customizing Jitsi stops feeling scary.

To sum up the key points:

• Start with config.js and the interface settings for quick wins.
• Use CSS, images, and language files for branding.
• Choose the IFrame API when you want to embed Jitsi in your own product.
• Build from source only when you truly need new features.
• Always test on staging, keep backups, and read release notes before upgrading.

Ready to try it? Set up a small test server today, change one thing (maybe the logo or the toolbar), and see how it feels. Once you have done one small change successfully, the bigger ones become much easier. If you get stuck, the Jitsi community forum and the GitHub repository are friendly places to ask questions.