Why your microphone works in one app but not another

You join a meeting. The microphone doesn't work. The browser already asked for permission once, you clicked Allow, the icon went green — and yet the level meter sits flat at zero and the host is asking if you can hear them. You spend ten minutes panicking, trying every dropdown in the meeting app, eventually drop the call and rejoin on your phone.

The fix is almost always one of three things. They are all called "permission" in casual conversation. They are entirely separate systems that don't know about each other, and granting one doesn't grant the others. Once you can name the three layers, the ten-minute panic compresses to about forty seconds.

The three layers of mic permission

From innermost to outermost: browser per-site permission, OS-level app permission, and per-app exclusivity. Any one of these blocks the chain. Granting one doesn't grant the others. This is the source of nearly every "but I clicked Allow!" frustration in the history of remote meetings.

An audio stream has to travel from the microphone hardware through the OS audio stack, into a specific application, and (for a web app) through that application's per-site permission system before it reaches the page. Each layer can say no on its own.

Browser per-site permissions

The innermost layer. The browser tracks per-origin permission separately for every site — granting Zoom.us access doesn't grant the page on this site access. Where to check:

• Chrome / Edge / Brave: padlock icon in the address bar → Site settings → Microphone. Toggle to Allow.
• Firefox: padlock icon → Connection details → More information → Permissions, or about:preferences#privacy → Permissions → Microphone → Settings.
• Safari: Settings → Websites → Microphone. Set the site to Allow or Ask.

If you've previously denied access for a site, most browsers won't show the prompt again automatically. You have to explicitly re-grant from the settings before the page can try again.

OS-level mic privacy

The middle layer. Every modern OS gates microphone access at the application level, on top of whatever the browser does:

• Windows 11: Settings → Privacy & security → Microphone. There's a global toggle that turns off the mic for every app, and a per-app allowlist underneath. If your browser isn't in the allowlist, the browser sees the device as absent, regardless of what permissions it has granted internally.
• macOS Sequoia: System Settings → Privacy & Security → Microphone. A per-app allowlist; the OS prompts the first time each app requests access. If you said no to the system prompt the first time Chrome asked, you have to manually toggle it on here — Chrome won't be re-prompted.
• Linux: messier. PulseAudio and PipeWire usually don't gate per-app, but the desktop environment may have its own privacy layer (GNOME Settings → Privacy on recent GNOME).

Per-app exclusivity quirks

The outermost — and most surprising — layer. Some apps acquire the microphone exclusively, meaning no other app can use it while they hold it. Older Zoom builds did this. Some games do it. Some voice-recording apps do it. When an exclusive holder is running, your browser sees a NotReadableError or "device in use" failure rather than a permission denial — the device is technically available, just not to you.

The fix is to quit the offending app. Not minimise. Not close the window. Fully quit, so the OS audio device is actually released. On macOS this means right-clicking the dock icon and choosing Quit, or Cmd+Q from the app itself. On Windows it means closing the system-tray icon, not just the window.

Default device vs picker permissions

When the browser asks for "your microphone", it usually means the OS default input. Switching default in the OS (Sound settings → Input → pick a device) and refreshing the page picks up the new default. Some browsers expose an explicit picker after the first permission grant — Chrome shows one from the address-bar permissions panel, Firefox bakes it into the initial prompt. Safari doesn't, and you're stuck with the OS default.

If you have a USB headset and a built-in laptop mic, and the page is picking up your laptop mic rather than the headset, this is almost always why: the headset isn't the OS default. Set it as default before opening the page, or use the browser's picker.

What the error messages actually mean

If you're debugging in the browser DevTools console, the getUserMedia API throws a small vocabulary of named errors. They map cleanly to the layers above:

• NotAllowedError — the user clicked Block, or the OS-level permission is off. Layer one or two.
• NotFoundError — no microphone detected. Either there isn't one (laptop with no built-in mic, no peripheral attached) or the OS has hidden it from this application.
• NotReadableError — the device exists and is permitted, but another app is holding it exclusively. Layer three.
• OverconstrainedError — the page asked for a configuration the device can't deliver (a specific sample rate, a specific device ID that no longer matches anything).
• SecurityError — the page is being served over HTTP rather than HTTPS. getUserMedia only works on secure origins (localhost is exempt for development).

A diagnostic flow

When the mic doesn't work and you don't know why, walk this list in order. Stop at the first step that produces a clear answer:

1. Test the mic in another app you know works — Voice Recorder on Windows, Photo Booth on macOS, the system Sound panel's input meter. If it's broken there too, it's hardware or OS — fix that before looking at the browser.
2. If the mic is fine in another app, open the microphone test on this site. If it's broken here, it's a browser-level issue.
3. Reset the browser permission for the origin (padlock → reset permissions, or remove the site from the microphone allowlist). Reload. Click Allow on the fresh prompt.
4. Reset the OS-level permission for the browser. On Windows, toggle the browser off and on in the Microphone allowlist. On macOS, toggle it off and on in Privacy & Security → Microphone.
5. Quit every other app that might be holding the device — especially Zoom, Teams, OBS, Discord, and any voice-recording software.

When to use the microphone test

The microphone test on this site is the fastest way to confirm the mic is producing signal, before joining any call. Click Start, speak normally, watch the level meter move. Thirty seconds, and you'll know whether you have a problem to solve before anyone is watching.

Related reading

The camera test covers the same set of layers for video. The browser diagnostic exports a full permissions report you can paste into a support ticket. And the existing pre-call checklist turns this article into the five-minute routine worth running before any important meeting.