What this online mic test checks
The first screen answers the common question quickly: is the selected microphone sending a signal to this browser? The live waveform and level meter respond as you speak. You can then record a temporary clip — start and stop it yourself — and play it back to check whether words are clear, the correct mic is active, and the capture contains obvious noise or distortion.
How to get a reliable microphone test result
- Select the input you plan to use. If several microphones appear, speak and watch which waveform moves.
- Use your normal position and voice. Test at the desk, headset position or phone distance you will actually use.
- Play back a short recording. Meters show signal level; playback reveals intelligibility, intermittent noise and the wrong mic.
- Change one thing and retest. Compare the same browser and device after changing distance, input gain, room noise or processing.
Choosing the correct microphone
Browsers generally reveal useful device names only after microphone permission is granted. The selector in the test lists the inputs exposed to this tab, including laptop arrays, webcam mics, USB interfaces and headset microphones. Choosing one here does not permanently change the operating-system default or another app's setting.
On a phone or tablet, there may be fewer selectable inputs even when an external or Bluetooth device is connected. Test the device name that the browser exposes, record a clip, and then confirm the same input inside the call or recording app you intend to use.
What the microphone readings mean
The level meter reads in dBFS, where 0 dBFS is the digital ceiling. Normal speech should register clearly on the meter: very low readings can make speech hard to recover, while levels that keep hitting the ceiling leave no headroom and distort. Your noise floor is what the meter shows while you stay silent — the combined level of the room, selected microphone, system gain and processing chain. The gap between speech and silence is your signal-to-noise ratio (SNR); a larger gap makes speech easier to separate from background noise.
Advanced input details shows the sample rate, channel count and the requested call processing — echo cancellation (EC), noise suppression (NS) and automatic gain control (AGC). Those features often help calls but can alter music and other recordings. These are browser capture-track settings, not a specification of the microphone hardware.
Why is my mic so quiet? Gain staging from mic to app
A quiet microphone is usually a gain-staging problem rather than a broken one. In this test, normal speech should average roughly −30 to −15 dBFS, where 0 dBFS is the digital ceiling. If speech reads below about −40 dBFS, raise the operating-system input level first — on Windows under Settings → System → Sound, on macOS under System Settings → Sound → Input — before touching any hardware knob on a USB interface. Automatic gain control in the browser or a call app can mask a low system setting for a while, then pump the level or amplify noise between sentences. Distance matters about as much as gain: halving the distance to a close microphone raises its level by roughly 6 dB. Change one stage at a time and retest. If speech still sits below −40 dBFS at full system gain, suspect the microphone, its cable or its port. The reference ranges on this page are troubleshooting heuristics, not hardware specifications.
Gain staging is easier to reason about as a chain: microphone sensitivity, then any analog preamp, then the operating-system input level, then browser or app processing. Raising the system slider lifts speech and room noise together, so SNR barely moves; moving closer raises speech without raising the room, which is why distance is the cheapest SNR improvement available. On the dBFS scale used here, a silent-room reading below −55 dBFS is acceptable for calls and below −65 dBFS approaches broadcast-grade quiet, while an SNR above 25 dB gives suppressors enough separation to work with. Connection type biases the result too: a 3.5 mm headset microphone depends on the computer's plug-in (bias) power and its often-noisy analog input stage, while a USB microphone or interface performs its own preamplification and conversion and bypasses that stage entirely.
Mic not detected or no waveform
- Check browser permission. Open the lock or tune icon in the address bar, allow microphone access for this site, and reload if the browser asks you to.
- Check operating-system permission. Windows and macOS can block microphone access even when the site setting appears allowed. Enable access for the browser in system privacy settings.
- Switch inputs in the test. A webcam, dock or disconnected headset may have become the default. Select each named input and look for movement while speaking.
- Check physical controls.Inspect headset mute switches, boom position, interface gain, cables and USB connection. Then compare the operating system's own input meter.
- Close conflicting apps and reconnect. If the device disappeared, reconnect it and restart the browser before assuming the microphone itself has failed.
Mic works here but not in Zoom, Teams or Google Meet
A successful browser test narrows the problem; it does not test a separate call app. Check that the app is not muted, has operating-system permission and is using the same named input. Also test the app's own meter before joining. The official setup guides cover device selection for Zoom, Microsoft Teams and Google Meet.
A microphone that passes a browser test but stays silent in Zoom, Microsoft Teams or Discord almost always has a device-selection or permission mismatch, not a hardware fault. Each application stores its own input choice, so it can remain pinned to a webcam, dock or previously connected headset long after the system default changed; open the app's microphone selector and pick the same device name this test used. Permissions are also scoped per application: Windows (Settings → Privacy & security → Microphone) and macOS (System Settings → Privacy & Security → Microphone) grant microphone access app by app, so allowing a browser does not allow a call client. On Windows, an application holding exclusive control of the device can silence every other consumer; that option lives in the device's advanced properties. After changing any of these settings, fully quit and restart the call app so it re-enumerates audio devices.
If the mic works here and in the app's pre-call meter but other people still cannot hear you, the next checks are the meeting mute state, selected device after joining, browser/app permissions, connection quality and the other participant's output. Those are outside this page's audio capture path.
What a web microphone test can and cannot confirm
It can check
- Whether this browser receives a live signal from the selected input.
- What the browser capture sounds like through temporary local recording and playback.
- Relative dBFS level while you speak and while the room is silent.
- Track settings and device labels that the browser exposes after permission.
It cannot check
- Calibrated dB SPL, microphone self-noise or objective frequency response without reference equipment.
- Whether Zoom, Teams, Discord or another application selected the same microphone.
- Network loss, call-server processing or what a remote participant actually hears.
- Hidden hardware faults that do not occur during this short test.
Why there is no dB SPL or self-noise figure
A browser microphone test cannot report calibrated loudness in dB SPL. Web Audio measures in dBFS — decibels relative to the digital ceiling of the capture path — and converting dBFS to sound pressure requires the microphone's sensitivity, the exact input gain and an acoustic calibration, none of which a web page can read as trusted values. The same voice at the same distance can register −40 dBFS on one laptop and −18 dBFS on another with neither reading being wrong. A browser also cannot isolate hardware self-noise: the quiet-window number on this page combines the room, the microphone, the input electronics and any active processing into one figure, so it describes call-path readiness rather than a component specification. Treat dBFS readings as relative — valid for comparisons on the same device and settings — and use a calibrated SPL meter when an absolute loudness number is required.
Method and review notes
This page uses the browser's Media Capture and Web Audio interfaces. Measurements are local and the method, thresholds and known limitations are documented on How we test. For the underlying browser standards, see the W3C specifications for Media Capture and Streams and Web Audio. Content and workflow reviewed .
Before your next important call
After checking the input, run the speaker test to confirm both output channels. The headphone test adds phase and listening-limit checks. Keeping input and output results separate makes the failing part easier to identify.