Why Isn't My Microphone Working?

A silent microphone is almost never just one problem. There are four separate things that can stand in the way, and all four have to be clear before any sound gets through: the browser's own permission, a permission in your computer's settings above that, another app that has already grabbed the microphone and won't share it, and a setting that picks which of your microphones is actually being listened to. Reinstalling a driver or buying a new headset fixes none of these, and in most cases the hardware was never the problem. Below, we go through the four in the order that finds the blocked one fastest, for each platform and each app, instead of by trial and error.

Permission comes first, and there are two of them

Before any app can hear you, two separate permissions have to be granted, and they live in different places. The first is the browser's own prompt, which our microphone test covers browser by browser. The second sits above the browser: a switch in your computer's settings that can block every app, including a browser you've already allowed, with no prompt and no error the page can see. Each platform keeps that switch somewhere different, so it's worth following the maker's own instructions rather than guessing.

Another app already has it

A microphone that's already in use can't always be opened a second time. On Windows this is documented behaviour, not a rumour. Microsoft's developer documentation for Windows audio says that "if an application opens a stream in exclusive mode, the application has exclusive use of the audio endpoint device that plays or records the stream," and that with the default settings, "a request by an application to take exclusive control of the device succeeds if the device is currently not in use... but the request fails if another application already has exclusive control of the device." In real life, that's the "could not be opened" or "already in use" error you get while a video-call app is still running in the background, sometimes just minimised rather than closed. The same documentation gives the fix: right-click the speaker icon, open Recording devices, select the microphone, open Properties → Advanced, and untick "Allow applications to take exclusive control of this device" if it needs to be shared. That checkbox and that error are Windows-only. Neither macOS nor the Linux desktops above have an equivalent switch, so on those, an app that can't open the microphone is much more likely to be blocked by the system permission from the section above than by the microphone being locked.

Tell it which microphone to listen to

Plugging in a headset, a webcam or a USB audio interface adds a new microphone rather than replacing the old one, and whatever was selected before stays selected until something changes it. Each operating system keeps this choice in its own sound settings, separate from the choice inside each app. On Windows, Microsoft's troubleshooting page has it at Settings → System → Sound, then in Input, "Choose a device for speaking or recording." On macOS, Apple's guide says "choose Apple menu > System Settings, then click Sound in the sidebar. Click Input, then select the device you want to use." On Linux, the GNOME Sound panel mentioned above does the same job under Input.

Every video-call app then keeps its own separate choice too, so a microphone that works in your system settings can still be ignored by the app. In Discord, the picker is under User Settings → Voice & Video, where Discord's troubleshooting guide for this exact problem has people choose their microphone from the Input Device dropdown menu, whatever your system has selected. In Zoom, open Settings, then the Audio tab. Zoom's support article describes a "Test microphone" button, and once you press it, "your audio will start recording and you will see the Input volume bar move when Zoom is picking up audio", so you can see which device is really being used instead of assuming. In Google Meet, the picker is on the preview screen before you join and again during the call: Google's own help page describes it as a dropdown next to the microphone icon, which you can open during a call with the arrow, or find in the same list under More options → Settings → Audio.

The record and play back part of our microphone test records at whatever sample rate and bit depth your browser and microphone agree on. What those two numbers mean, and why they matter beyond fixing a microphone, is explained in sample rate and bit depth.

Check for a mute button no screen can show

A muted microphone and a broken one look exactly the same: silence, with no error from the browser, your computer or the app. That's why this check comes last. Software can't see a physical mute, so you can only rule it out once everything software can see has checked out. Microsoft's guidance for Teams is clear about where to look: "Some mics have physical mute options on the devices themselves. Check that your headphone boom is not in the mute position... or that your external mic's physical mute button is not turned on." Microsoft's general Windows microphone page says the same more briefly, "If your headset has a Mute button, make sure it isn't active", and Discord's troubleshooting guide puts the same step before anything in Discord's own settings: "Check to see that you don't have a hardware mute engaged on your computer." It's easy to overlook, which is why everyone lists it.

Check it, don't guess

You can check each of these four things instead of taking them on faith. On our microphone test, the permission prompt only appears when you press Start listening, never when the page loads. When we tested it for this guide, permission changed from "ask" to "allowed" on that click and the level meter came alive straight away, which is exactly what all the settings above are there to allow. The list of microphones on that page is blank until you give permission, because browsers hide device names until then and only fill them in once you allow access. A blank list at first is that working as intended, not a bug. And in a full session we recorded during testing, allowing access, listening, recording 2.6 seconds and playing it back, every request the page made was it loading its own files. Nothing was sent anywhere, and nothing you recorded left the device.

What a working meter can't tell you is whether what you just recorded is safe to play back loudly through headphones. That's a separate question about how loud your output is, not your microphone, and how loud is too loud covers it.