What a mic test can actually prove
A microphone sits at the end of a chain, and every link in it can break independently: the capsule, the cable or radio link, the operating system’s device selection, the browser’s permission, and finally the app you were trying to talk in. This page tests the first four. If your voice draws a waveform here, then the hardware works, the OS is delivering it, and the browser is allowed to read it — which means a call where nobody can hear you has a fault in that call’s software, not in your microphone. That single split saves most of the time people spend swapping cables.
It also catches faults a yes/no test cannot. A microphone can be working and still be unusable: fifteen decibels too quiet, clipping on every consonant, or being aggressively de-noised into a robot. Those show up as numbers and as sound, which is why this page gives you both a meter and a playback button rather than a green tick.
Reading the level: dBFS, peak and RMS
The meter is in dBFS — decibels relative to digital full scale. Zero is the loudest value the format can represent, so every real signal is a negative number, and the scale is logarithmic: each 6.02 dB down is half the amplitude. The bar draws two things at once. The wide coloured bar is the peak, the single largest sample in the last window. The thin white bar inside it is the RMS, the energy of the whole window, which tracks how loud you actually sound.
They are never the same number and the gap matters. Speech is spiky: the sample trace this page draws before you grant permission peaks at -12.3 dBFS while its RMS sits at -21.3 dBFS — a crest factor of 9.0 dB. Set your gain so the RMS looks healthy and your peaks are already past the ceiling. Set it by the peak and you have headroom for the moment you laugh.
| Band | Peak range | What MicTester tells you |
|---|---|---|
| Nothing arriving | below -50 dBFS | Below −50 dBFS there is no usable speech in the signal. Either the wrong input is selected, the device is muted in hardware, or nobody is talking. |
| Too quiet | -50 to -20 dBFS | Audible, but the far end will strain. Raise the input gain until your loudest speech peaks land above −20 dBFS. |
| On target | -20 to -9 dBFS | Speech peaks belong in this window. It is the band between the alignment level and the permitted maximum, so you have headroom for a laugh or a cough. |
| Hot | -9 to -0.5 dBFS | Loud enough that a sudden peak can hit the ceiling. Fine if your speech only touches this band; back the gain off if it lives here. |
| Clipping risk | -0.5 dBFS and above | At the ceiling. Anything louder cannot be represented and comes out as distortion that no amount of processing downstream will remove. |
Where these four boundaries come from. −50, −20, −9 and −0.5 dBFS are the thresholds OBS Studio publishes for its own input-level indicator, in the knowledge-base article “Audio Mixer Technical Details” dated 2022-02-13, read directly on 2026-08-15. MicTester reuses them so a reading here means what a reading there means. The band names and the advice in the last column are this site’s own reading of those levels — they are a scale we declare, not a survey of anyone’s microphones, and we have measured no population to support them. Your own reading depends on your microphone, its gain, your distance from it and your voice — which is precisely why this page measures yours instead of publishing an average.
Amplitude and dBFS, converted exactly
Every figure in this table is 20 · log₁₀(amplitude) and its inverse — arithmetic you
can reproduce with a calculator. The last column is the useful one in practice: it tells you how
much gain moves that reading onto the −20 dBFS alignment level.
| dBFS | Amplitude | 16-bit sample | Power ratio | Gain to −20 dBFS | Band |
|---|---|---|---|---|---|
| 0 | 1 | 32,767 | 100% | -20 dB | Clipping risk |
| -1 | 0.89125 | 29,204 | 79.4328% | -19 dB | Hot |
| -3 | 0.70795 | 23,197 | 50.1187% | -17 dB | Hot |
| -6 | 0.50119 | 16,422 | 25.1189% | -14 dB | Hot |
| -10 | 0.31623 | 10,362 | 10% | -10 dB | On target |
| -12 | 0.25119 | 8,231 | 6.3096% | -8 dB | On target |
| -18 | 0.12589 | 4,125 | 1.5849% | -2 dB | On target |
| -20 | 0.1 | 3,277 | 1% | 0 dB | On target |
| -24 | 0.0631 | 2,067 | 0.3981% | +4 dB | Too quiet |
| -30 | 0.03162 | 1,036 | 0.1% | +10 dB | Too quiet |
| -40 | 0.01 | 328 | 0.01% | +20 dB | Too quiet |
| -50 | 0.00316 | 104 | 0.0010% | +30 dB | Too quiet |
| -60 | 0.001 | 33 | 0.0001% | +40 dB | Nothing arriving |
Two rows are worth memorising. −6 dBFS is half amplitude: the exact figure is −6.0206 dB, which is why doubling your distance from a microphone, or halving the gain knob, moves the meter by about six. And −20 dBFS is a tenth, exactly, because 20 · log₁₀(0.1) is −20 — a rare case where the round number in dB is also round in amplitude.
What your browser lets a page ask for
When this page opens your microphone it does not simply ask for “audio”. It passes a constraints object, and the web platform defines exactly which knobs exist in it. The list below is the audio section of the Media Capture and Streams specification — W3C Candidate Recommendation Draft, 09 October 2025 — with the types taken from the same document’s WebIDL. It was published on w3.org with no paywall; read directly on 2026-08-15.
The last column is the only honest way to answer “does my browser support this”. MDN’s
browser-compat dataset carries no entries for individual constraints — there is no file for
MediaTrackSupportedConstraints in it at all — so a per-browser table here would be
invented. Instead the page asks your browser directly with
getSupportedConstraints() and fills the column in as you read it.
| Constraint | Type | Unit | What it controls | Your browser |
|---|---|---|---|---|
sampleRate | ConstrainULong | samples per second | The sample rate for the audio data. | — |
sampleSize | ConstrainULong | bits | The linear sample size in bits. As a constraint it can only be satisfied by devices that produce linear samples. | — |
echoCancellation· in the tool | ConstrainBooleanOrDOMString | on / off / mode | Removes sound the system is playing back out of what the microphone records. The spec added two named modes, "all" and "remote-only", on top of true and false. | — |
autoGainControl· in the tool | ConstrainBoolean | on / off | Lets the browser ride your input level up and down for you. The spec notes cases where you want it off so the audio is not altered. | — |
noiseSuppression· in the tool | ConstrainBoolean | on / off | Strips steady background noise. Same caveat as gain control: sometimes you want the signal untouched. | — |
latency | ConstrainDouble | seconds | Target time between a sound happening and the data reaching the next step. The spec says the real latency may vary from the target. | — |
channelCount | ConstrainULong | channels | How many independent channels the audio carries — samples per sample frame. | — |
deviceId· in the tool | ConstrainDOMString | opaque string | Picks one specific device. Useful for the initial choice, not for changing device later; getCapabilities() returns only the single current value. | — |
groupId | ConstrainDOMString | opaque string | Ties devices belonging to one physical unit together — the spec’s own example is the microphone and the earpieces of the same headset. | — |
Three of those names are the switches in the tool above — echoCancellation,
noiseSuppression and autoGainControl — and what each one does to your
voice is the next section. The finer points, including the named modes echo cancellation accepts
and the one constraint MDN still documents that the specification no longer contains, are set out
on what this site measures.
What the three switches really do
Echo cancellation, noise suppression and automatic gain control are three different pieces of processing that get lumped together as “the browser cleaning up my audio”. They fail in different ways, and the fastest way to tell which one is hurting you is to turn them off one at a time while you talk.
Echo cancellation
It subtracts what your speakers are playing from what your microphone hears. Without it, a call on open speakers turns into a howl within a second. Its cost is that it needs a model of the room, and while it is building one it can duck your voice — which is why the first two seconds after you unmute sometimes sound thin. On a headset there is no acoustic path from earpiece to mic worth cancelling, which is why the headset mic test starts with it off.
Noise suppression
It removes sound it classifies as not-speech: fans, air conditioning, traffic, keyboard clatter. The specification’s own note is that there are cases where you want it off so the audio is not altered, and that is the honest summary. Turn it off here and speak quietly: if words that vanished with it on suddenly arrive, the suppressor was eating you, not the fan.
Automatic gain control
It rides your level for you, pulling quiet speech up and loud speech down. It is the reason a microphone can be badly misconfigured and still sound acceptable — and the reason a genuinely quiet microphone is so hard to diagnose. The too-quiet page switches it off deliberately for that reason.
A test that means something, in five steps
- Start, and say one ordinary sentence at the distance you will actually sit. Whispering into the grille tells you nothing about your meeting.
- Read the hold figure, not the wobble. The peak bounces; the hold keeps the loudest thing you did. Aim to land it between -20 and -9 dBFS.
- Record ten seconds and listen. Numbers cannot hear a crackle, a hum or a suppressor chewing the start of every word. You can.
- Toggle each switch once while talking, and notice which one changes how you sound. That is the setting to go and find in your conferencing app.
- Check the device list. If your laptop lid array is selected while you are wearing a headset, everything above is measuring the wrong microphone.
Where this test stops
- It cannot see your conferencing app’s settings. A pass here plus silence in Zoom means the fault is in Zoom, and the Zoom page lists the exact panel to open.
- It cannot separate the microphone from the port. Try another USB socket or another machine to split those.
- It cannot tell you what your voice sounds like to a listener on a bad connection. Codecs and packet loss happen after this page ends.
- It cannot measure absolute sound pressure. dBFS is a digital scale with no fixed relationship to decibels in the room; a reading here is not a noise measurement.
- It cannot benchmark your hardware against other people’s. We have measured no microphones and publish no such comparison — see what this site does and does not measure.