Mic and speaker test
Check your microphone and your speakers on one page, in the order that gives a result you can trust — output first, input second.
Last reviewed on August 26, 2026
Check your microphone and your speakers on one page, in the order that gives a result you can trust — output first, input second.
Last reviewed on August 26, 2026
Most audio complaints are really two questions wearing one coat: can other people hear me, and can I hear them? This page runs both checks together — a speaker test for output and a microphone test for input — so you can tell in about a minute which half is actually at fault. Both halves run locally in your browser, and no audio is recorded or uploaded.
Do the speaker test first. If your output is broken, every subsequent test looks broken too, and you will spend twenty minutes fixing a microphone that was fine all along.
Output and input fail for entirely different reasons, and only one of them involves a permission prompt.
Playing sound is not privacy-sensitive, so browsers do it without asking. That makes the speaker test a clean, unambiguous signal: if you hear the tone, the browser, the operating system's output routing, the volume chain, and the speaker itself are all working. Almost nothing can hide.
Reading a microphone is privacy-sensitive, so it always requires an explicit permission that the browser remembers. That adds two extra failure points on top of the hardware — a blocked permission and an operating-system privacy switch — neither of which produces an error you would notice. Checking output first removes it from the equation before you start on the harder half.
The value of testing both halves together is that the combination narrows the cause far faster than either test alone.
| Speakers | Microphone | What it points at | Where to go |
|---|---|---|---|
| Working | Working | Your hardware is fine. If a specific app still fails, the fault is that app's own device preference. | Zoom, Teams and Discord |
| Working | Nothing | Output is ruled out. Look at browser permission, input device selection, a hardware mute, or another app holding the mic. | Microphone not working |
| Nothing | Working | Input is ruled out. Almost always the selected output device rather than a broken speaker. | Sound test fix order |
| Nothing | Nothing | Something upstream of both — a docking station, a headset that has disconnected, or an audio service that has stopped. | Microphone not detected |
The middle two rows are where most people are, and both are far more often a settings problem than a hardware one.
If you are testing before a meeting rather than debugging a fault, this is the sequence worth building a habit around:
Levels tell you whether a signal exists. They do not tell you whether you sound good. Room reverberation, plosives, a fan behind the microphone, and Bluetooth profile switching all pass a level test comfortably and still make you hard to listen to.
For that, record a few seconds and play it back with the record and playback tool. Listening to yourself is unpleasant and completely diagnostic: if you sound distant, echoey, or muffled to your own ears, you sound worse to everyone else. If a wireless headset is involved and the recording sounds thin, that is the narrowband calling profile at work rather than a fault.
Measuring how loud the room itself is with the sound level meter is worth doing too — voice recognition and noise suppression both degrade sharply above roughly 60 dB of background noise.
Test the output first, then the input. Play the left and right tones to confirm sound is coming out, then start the microphone test and speak normally. Output first matters, because a broken output makes a working microphone look broken too.
Playing sound is not privacy-sensitive, so browsers allow it silently. Reading a microphone is, so it always needs an explicit prompt — one you can revoke at any time from site settings.
Yes as a first check — it verifies hardware, browser, and OS in under a minute. It cannot verify the meeting app's own device selection, which is stored separately and is the usual reason a working mic is still silent on a call.
That rules out your output entirely and points at the input chain: a blocked permission, the wrong input device, a hardware mute switch, or another application holding the microphone exclusively.
No. Both halves run entirely in your browser. The microphone signal is analysed for level and waveform, then discarded — never stored, never sent anywhere.
You can, though a headset has quirks of its own — boom mutes, plug types, and profile switching on calls. The dedicated headset test covers those.