Why Isn't My Microphone Working?

A silent microphone is almost never one problem. It is the visible end of up to four separate gates stacked in series — the browser's own permission, an operating-system permission sitting above that, another application that has already opened the device and won't share it, and an input selector that decides which of several devices actually feeds whatever is listening — and every one of them has to be open at once before any sound gets through. Reinstalling a driver or buying a new headset fixes none of these, and in the great majority of reports the hardware was never the problem to begin with. What follows checks the four gates in the order that actually finds the blocked one, platform by platform and app by app, rather than by trial and error.

Permission is the first gate, and it has two locks

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 this site's microphone test covers per browser in detail. The second sits above the browser entirely: an operating-system switch that can block every app on the machine, including a browser the person has already allowed, with no prompt and no error the page itself is able to read. Each platform keeps that switch somewhere different, and the exact wording is worth reading from the vendor rather than guessing.

The app that already has it

A device that is open cannot always be opened twice. On Windows specifically, this is a documented, named behaviour rather than a rumor: Microsoft's own developer documentation for the Windows audio engine states 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 practice that is the "could not be opened" or "already in use" error a second app throws while a conferencing tool is still running in the background, sometimes 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 clear "Allow applications to take exclusive control of this device" if it needs to be shared. This particular checkbox and this particular error are Windows specifics — neither macOS nor the Linux desktops covered above ship an equivalent consumer-facing exclusive-mode toggle. On those two, a microphone an app refuses to open is far more often the OS-level permission from the section above still sitting closed than the hardware being genuinely locked.

Tell it which input to actually 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 app-level choice below. On Windows, Microsoft's own 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 cited above does the same job under Input.

Every conferencing app then keeps a second, independent choice of its own, and a device that works in the operating system can still be ignored by the app. In Discord, the picker sits under User Settings → Voice & Video, where Discord's own troubleshooting guide for this exact symptom has people choose their microphone from the Input Device dropdown menu there, independently of whatever the operating system has selected. In Zoom, open Settings, then the Audio tab: Zoom's own support article has a "Test microphone" button, and once pressed, "your audio will start recording and you will see the Input volume bar move when Zoom is picking up audio" — a direct way to confirm the selected device rather than assume it. In Google Meet, the picker is on the preview screen before joining and again once inside the call: Google's own help page describes it as a dropdown next to the microphone icon, reachable during a call by clicking the arrow and, from there, the same device list under More options → Settings → Audio.

The record-and-playback stage on this page's own microphone test captures at whatever sample rate and bit depth the browser and the selected device agree on. What those two numbers actually mean, and why they matter well beyond troubleshooting a mic, is covered separately in sample rate and bit depth.

Rule out a mute nothing on screen can show you

A muted microphone and a broken one produce the identical result — silence, with no error from the browser, the operating system or the app — which is exactly why this check has to come last rather than first: a mute is invisible to software, so it can only be ruled out once everything software-visible has already checked out. Microsoft's own guidance for a conferencing app is explicit 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 troubleshooting page makes the same point more briefly — "If your headset has a Mute button, make sure it isn't active" — and Discord's own troubleshooting guide lists exactly the same step before anything inside Discord's own settings: "Check to see that you don't have a hardware mute engaged on your computer." Three vendors naming the same overlooked switch independently is a stronger reason to check it than any one of them alone.

Confirm it, don't guess

Each of the four gates above can be checked rather than taken on faith. On this site's own microphone test, the permission prompt is wired to fire from the Start listening button itself, not from page load — in testing done for this page, permission state moved from prompt to granted on that click, and the level meter was live immediately afterward, which is the exact behaviour every setting above exists to allow. The input-device list on that same page is deliberately blank until permission is granted, because browsers withhold real device names beforehand by design and fill the picker with them only once access is allowed; a blank picker on first load is that behaviour working as intended, not a bug. And across a full session recorded during this site's own testing — granting access, listening, recording 2.6 seconds of audio and playing it back — the page made eleven network requests in total, every one a first-party asset load, with no fetch, no XHR, no beacon and no websocket call anywhere in the trace. Nothing captured left the device.

What a working meter on that page cannot tell you is whether the level you just watched move is safe to listen back to over headphones at volume — that is a separate question about output loudness, not input, and how loud is too loud covers it on its own terms.