MicTester is a static web page that opens your microphone with your permission, draws what it sees, and tells you what the numbers mean. There is no account, no upload and no server-side component. This page exists to say precisely where every figure on the site comes from, because a tool that prints decibels ought to be able to show its working.
The three kinds of number on this site
Every figure printed anywhere here is one of exactly three things, and the pages say which:
- Arithmetic. The dBFS conversion table, the gain table and the buffer-latency table
are generated at build time from
src/lib/dbfs.tsand asserted cell by cell in the test suite, which the build runs before it will produce a page. No hardware is involved and none is implied. You can reproduce any cell with a calculator. - A reading from your own device. Your peak, your RMS, your reported sample rate,
your
baseLatency, your device list. These are measurements — of your machine, taken on your machine, at the moment you look. They are not comparable with anyone else’s and are never stored. - A quotation from a named document. Menu paths, constraint definitions, meter thresholds. Each carries the document, its own date, and the date it was read.
There is deliberately no fourth kind. This site publishes no measurements of microphones, no survey of what levels people record at, and no comparison of hardware or browsers by performance. We own no microphone array, no second operating system and no browser-automation rig, so any such table would be invented, and an invented table is worse than no table.
Where the reference marks came from
The meter’s guide marks sit at -20 and -9 dBFS, and its five bands change at −50, −20, −9 and −0.5 dBFS. Those four boundaries are not ours: they are the values OBS Studio publishes for its own input-level indicator in its knowledge-base article “Audio Mixer Technical Details”, dated 2022-02-13, which we read directly on 2026-08-15. We reused them so that a reading here means the same thing as a reading in a mixer many of our readers already have open.
What is ours is the naming and the advice — calling −20 to −9 “on target”, calling below −50 “nothing arriving”. That is a scale this site declares, and the component that draws it carries that sentence on every page it appears on, so the claim can never travel without its caveat. It is not derived from measuring anybody.
One sourcing note we owe the OBS project: its knowledge base carries a banner asking that its pages not be linked to users while it remains a work in progress. We cite its articles by title and date throughout and do not deep-link them.
The specification behind the tool
Constraint names, types and behaviour come from the Media Capture and Streams specification — W3C Candidate Recommendation Draft, 09 October 2025. It was published on w3.org with no paywall; read directly on 2026-08-15. Where the site says the specification defines something, we searched the published text for it rather than recalling it. Two results of that search are worth printing, because both correct something a reader may have picked up elsewhere.
The first is that echoCancellation is the only constraint in the audio set that is
partly boolean — the single ConstrainBooleanOrDOMString in the list — because
the specification defines two named modes on top of true and false.
"all" — Remove every sound the system is playing, notifications and screen readers included. The spec frames this as the maximum-privacy option. "remote-only" — Remove only audio arriving from WebRTC peer connections, so locally played sound still gets transmitted. The spec’s example is a remote music lesson.
The second is that volume is still documented on MDN as a constraint
but does not appear anywhere in the current specification text: searching the whole document for the
word returns nothing. A page asking for it is asking for something that is no longer defined.
Which browsers can run this page
The per-constraint support question is answered live on the hub, by asking your browser. The per-API question can be answered from a published dataset, and this is it: the first version of each browser in which the APIs this tool calls became available.
| API | What it does here | Chrome | Edge | Firefox | Safari |
|---|---|---|---|---|---|
mediaDevices.getUserMedia()Requires a secure context. Everything else on this page is downstream of it. | Opens the microphone at all | 53 | 12 | 36 | 11 |
mediaDevices.enumerateDevices()Firefox listed input devices from 39 but returned no output devices until 116. | Fills the input-device list | 47 | 12 | 116 | 11 |
mediaDevices.getSupportedConstraints()The source of the live column in the constraint table on the hub. | Says which switches your browser recognises | 53 | 12 | 44 | 11 |
MediaStreamTrack.applyConstraints()MicTester falls back to reopening the stream where this rejects. | Flips a switch without reopening the mic | 59 | 12 | 43 | 11 |
MediaStreamTrack.getCapabilities()The newest of the set — Firefox only shipped it in 132. | Asks the device what it can do | 59 | 12 | 132 | 11 |
MediaRecorderContainer and codec support differ per browser; the tool asks isTypeSupported() rather than assuming. | Records the clip you play back | 47 | 47 | 25 | 14.1 |
AnalyserNodeThe lowest Chrome and Safari versions in this table — 14 and 6. Firefox shipped it in 25, the same release as MediaRecorder. | Feeds the waveform and the spectrum | 14 | 12 | 25 | 6 |
AudioContext.baseLatencyRead on the latency page. Absent browsers simply show a dash. | Reports the graph-to-hardware delay | 58 | 58 | 70 | 14.1 |
How the tool is built
Your browser hands the page a media stream. It is connected to a Web Audio analyser node, which the
page polls once per animation frame for time-domain samples and frequency data. The peak is the
largest absolute sample in the window and the RMS is the root mean square of the same window, both
converted with 20 · log₁₀. The recorder is a MediaRecorder writing into your
tab’s memory and handing back a blob URL for the audio element.
The analyser is deliberately not connected to your speakers. Routing a live microphone to the output is how feedback howls start, and no mic test should risk one. Playback happens only from a recorded clip, on a control you press.
What this site cannot do
- It cannot measure sound pressure in your room. dBFS is a digital scale with no fixed relationship to decibels in air.
- It cannot see inside Discord, Zoom, Teams or OBS. It can only tell you the microphone works before those apps get it.
- It cannot separate a faulty microphone from a faulty port, cable or driver — only swapping can.
- It cannot measure the acoustic round trip from your mouth to your ears; it reads the delay figures your browser reports and shows the arithmetic behind them.
- It cannot verify which Bluetooth mode your headset negotiated; the reported sample rate is the closest evidence available to a web page.
- It gives no medical, legal or financial advice, and nothing here is a hearing test.
Corrections
Menu paths rot and specifications move. Every page names its sources and the date they were read, so you can see exactly which claim has gone stale and what it was resting on. If you find one — a renamed setting, a moved panel, a figure that does not reproduce — send it over. Corrections to sourced claims are the most useful mail this site gets.