The headset problem nobody tests for
Ask someone to test their headset and they will talk into it and check whether they can hear themselves. That confirms sound exists. It does not confirm the sound came from the boom microphone rather than the laptop lid — and on a modern laptop those two produce audibly different results while both counting as “working”. Being heard from the wrong microphone is a fault that never shows up as a failure, which is why it survives every test people normally run.
Browsers happen to publish exactly the information needed to settle it, and almost no tool uses it. Every audio device carries four fields, and one of them exists specifically to say these two entries are one piece of hardware.
What the browser publishes about each device
| Field | Type | What the specification says | Why it matters for a headset |
|---|---|---|---|
deviceId | DOMString | Identifies one device uniquely alongside its kind, and is stable across visits once you have granted access. The spec requires it to be treated like a cookie: not persisted for sites blocked from cookies, and rotated when other storage is cleared. | What a page stores if it wants to reopen the same headset next time. Clearing site data changes it, which is why a remembered device choice sometimes resets. |
kind | MediaDeviceKind | One of exactly three values: "audioinput", "audiooutput", "videoinput". | A USB headset appears twice — once as audioinput for its boom mic, once as audiooutput for its earpieces. They are separate entries, not one device. |
label | DOMString | A human-readable name such as "External USB Webcam". The spec warns that applications cannot assume it contains any particular information, and it is the empty string when the device has none. | The only thing that lets you tell "Headset Microphone" from "Microphone Array" — and it is blank until permission is granted, which is why the picker looks useless before you press Start. |
groupId | DOMString | Shared by every device belonging to the same physical unit, and generated freshly for each document. | The spec’s own worked example is a headset: its microphone and its earpieces carry the same groupId. Matching on it is how you confirm you are recording and monitoring through the same piece of hardware. |
Devices come in exactly three kinds and no others:
audioinput — an audio input device; the spec’s example is a microphone., audiooutput — an audio output device; the spec’s example is a pair of headphones., videoinput — a video input device — listed here only because it is the third of exactly three values. There is no “headset” kind, and there never will be. A headset is two entries that happen to
share a group.
Reading the answer above
Open the Input device tab. Under the picker, one of two sentences appears. Either your selected microphone shares a group with a named output — in which case they are the same physical unit and you are recording through the headset — or no output shares its group, in which case nothing your browser reports pairs that microphone with a speaker. On a laptop the second answer often means the built-in array, with the headset on your head doing nothing but playing sound. Often, not always: that part is a reading of the situation, not something the browser told you.
The first answer is a definite one, because the specification defines groupId that way: two devices share a group identifier when they belong to the same physical device. What it does not do is define the converse. It never says an unpaired entry must be a separate piece of hardware, and a browser is free to hand back an empty group identifier and tell you nothing at all — which is why the panel gives that case its own third sentence instead of folding it into “standalone”. The specification also requires the identifier to be generated per document, so it cannot be stale or cached from a previous visit. That explains a behaviour people find odd: the group identifier is different on every site, and different again after you clear site data. It identifies a relationship, not a device.
A four-step headset check
- Press start and grant permission. Only now do device names become readable — the specification allows a browser to give an empty label, and every browser withholds real ones until access is granted.
- Select the headset microphone and read the group sentence. If it does not name your earpieces, you have found the fault before testing anything else.
- Talk normally and read the peak hold. A boom sits close to your mouth, so a healthy headset usually reaches the target band without any gain adjustment at all. Landing at −40 means something is attenuating you.
- Record ten seconds and listen on the same headset. This is the step that catches what a meter cannot: a cable crackle when you turn your head, a hum that appears only on battery power, a boom that pops on every plosive because it has drifted in front of your lips, when the corner of your mouth is where it belongs.
Faults, and which of them this page can see
- Wrong device selected — visible here, definitively, via the group match.
- Hardware mute engaged on the cable — visible as a level of exactly −∞. Digital silence and quiet look completely different on the meter.
- Boom too far away — visible as a peak below the target band while the recording still sounds clean. Distance is the whole cause: in a free field every doubling of it costs about 6 dB, so a boom that has drifted from the corner of your mouth to the side of your chin has given away decibels you can put a number on.
- Plosive popping — audible in playback, invisible on a meter until it clips.
- Intermittent cable — audible in playback while you move, which is why the recorder is worth ten seconds of your time.
- A dead earpiece — not visible here. That is an output fault and this page tests input.
- Which Bluetooth profile your link is using — not visible directly. The reported sample rate in the track readout is the closest evidence a web page can offer.
Once the headset checks out
If the group matches, the level is in the target band and the playback sounds like you, the headset is not your problem — and a call where people still cannot hear you has a fault in that app. The Teams page is the one to read next if you are on a work machine, since Teams keeps three separate device choices and is the likeliest to have kept an old one. For a voice channel, the Discord page covers input modes and server mutes, neither of which any hardware test can detect.