First decide who is affected, because the fixes are different:
- Only you: a permission, another app or the wrong device. Start with the next section.
- Several people on the same server: ask the administrator to investigate. Start with HTTPS, then distinguish local device access from a media or network problem.
Match the symptom before changing settings
| What you see | First check | How to verify |
|---|---|---|
| Permission denied or a blocked camera/mic icon | Browser permission for the exact meeting website | Reload, select the device and check the preview again. |
| Camera or microphone missing from the device list | Connection, physical switch, system permission and other apps | Confirm the device works in the system’s camera or sound settings. |
| Preview works, but others cannot hear or see you | Mute controls and selected input; then the meeting’s media path | Ask a consenting participant to confirm reception. A local preview alone is not a network test. |
| You cannot hear others, but the microphone works | Selected speaker/headset, volume and browser-tab mute | Check system audio output, then recheck the meeting. |
| Two-person calls work but a third participant breaks media | Bridge connectivity and server networking | Use the three-participant troubleshooting guide. |
This page is based on browser vendor documentation and Jitsi configuration behavior. The browser steps have not been run on every browser and device, and menu names change between versions.
If only you are affected
If sound is present but repeats, doubles or rings, use the echo and feedback checklist to isolate duplicate devices and the returning audio path.
Work through these in order and reload the meeting page after each change.
1. Allow the site in your browser
Jitsi can only use your devices after the browser lets it. If you clicked Block once, the browser remembers it.
- Chrome (desktop): click the icon at the left of the address bar, set Camera and Microphone to Allow, then reload. You can also open Settings, Privacy and security, Site settings, then Camera or Microphone, and change the site’s permission. Chrome documents this in its camera and microphone help.
- Firefox: click the permissions icon at the left of the address bar, remove the blocked camera or microphone entry, then reload and choose Allow when asked. Firefox also lists site permissions under Settings, Privacy and Security, Permissions. See Mozilla’s permissions help.
- Safari (Mac): open Safari, Settings, Websites, then Camera and Microphone, find the Jitsi website and choose Allow. See Apple’s Safari help.
- Edge and other Chromium browsers: the address bar icon and Site settings work the same way as in Chrome.
- Phone browsers: use the browser’s site settings, and also check the phone’s own permission for that browser (step 3).
2. Close other apps using the camera
Another video app, a recording tool or a second browser tab may be holding the camera. Close Zoom, Teams, OBS or other tabs using it, then reload Jitsi. Some webcams can serve only one app at a time.
3. Check operating system privacy settings
The browser itself may be blocked by the system.
- macOS: System Settings, Privacy and Security, Camera and Microphone, and enable your browser.
- Windows 11: Settings, Privacy & security, then Camera or Microphone. Check device access and the applicable app access controls. Desktop browsers also use Let desktop apps access your camera/microphone; they may not have an individual app toggle.
- Windows 10: Settings, Privacy, then Camera or Microphone. Check device access and Allow desktop apps to access your camera/microphone. See Microsoft’s version-specific instructions.
- iPhone and iPad: Settings, then your browser, then Camera and Microphone.
- Android: Settings, Apps, your browser or the Jitsi Meet app, Permissions.
4. Pick the right device
Open the arrow next to the microphone or camera button, or the settings before you join, and select the correct device. Headsets and virtual cameras are easy to select by mistake, and a muted headset looks like a dead microphone.
If a connected headset uses the wrong microphone, plays through laptop speakers or changes quality during a call, follow the headset routing and Bluetooth sound checks. That guide separates local input/output selection from meeting delivery.
5. Try another browser and remove blockers
Try a current supported browser or a separate browser profile to compare results. If you suspect an extension, temporarily pause only that extension for the trusted meeting site and restore it after the check. A private window has its own permissions and may still allow extensions, so it is not proof that permission or extension issues are excluded. On a work or school device, ask IT if settings are managed.
If the camera works elsewhere but not in Jitsi, and you joined a room on a company server, tell the server administrator the browser, device and what the screen showed.
Everyone is affected: check HTTPS
Browsers expose the camera and microphone only in a secure context: an HTTPS page with a certificate the browser trusts. If your Jitsi opens over http://, or over https:// with a self-signed certificate, it cannot use devices properly.
Ask the administrator to check which service owns TLS before editing Docker settings. A host reverse proxy and the Jitsi container should not compete to issue certificates or bind port 443. Follow the applicable SSL guide or reverse-proxy guide for that deployment.
To check quickly, open the meeting address in a browser and confirm there is no certificate warning and the address starts with https://.
Embedded Jitsi (iframe or IFrame API)
The parent page must be HTTPS, and the iframe must be granted access:
<iframe src="https://meet.example.com/room"
allow="camera; microphone; display-capture; autoplay; clipboard-write; fullscreen"></iframe>This is a permission-delegation example, not a complete embedding integration. The parent’s Permissions-Policy response header can still block camera or microphone access, and the user must grant permission. The Jitsi IFrame API creates an iframe with permissions, but cannot override the parent’s policy or the browser’s decision. See the IFrame API guide and browser media-access requirements.
Confirm the fix
Reload the trusted meeting page, choose the intended input and output devices, and check the preview. In a meeting you are authorized to use, ask another consenting participant to confirm that your audio and video arrive. If the preview works but reception fails, give the administrator the browser/version, symptom and whether the failure starts when a third participant joins. A device permission fix does not establish that bridge or TURN networking works.
Sources and verification scope
Reviewed October 20, 2026 against Chrome, Firefox, Safari, Windows and MDN media-access documentation. These are documentation-backed steps, not a claim of end-to-end testing on every listed device or a recording of your camera or microphone.
Who can fix what
| Situation | Who can fix it |
|---|---|
| Browser or system blocked the camera | You, in browser and system settings |
| Camera in use by another app | You |
| Certificate warning or unsupported-browser message for everyone | The server administrator |
| Embedded page missing permissions | The developer of the embedding page |
| Meeting link, password or lobby | The organizer, see Jitsi login, moderator and password prompts |
| Screen sharing fails or is greyed out | You or the moderator, see screen sharing not working |
New to Jitsi? How to join or start a Jitsi meeting covers the prejoin screen where you check your devices.
Still stuck?
Ask an engineer and include the browser, the device and whether everyone or one person is affected.