Two gates, not one

The microphone is behind two independent permission layers, and most “the site can’t hear me” mysteries are people fixing the wrong one:

1. The OS gate — whether the browser application may touch the microphone at all. On macOS it’s System Settings → Privacy & Security → Microphone with a per-app checkbox; on Windows it’s Settings → Privacy & security → Microphone with a master switch plus per-app toggles. If this layer says no, every site in that browser fails silently — no prompt, just a dead request.
2. The browser gate — the per-origin prompt you actually see. Chrome/Edge put it in the address bar’s lock/tune menu; Firefox shows a door-hanger with a remember checkbox; Safari asks via a dialog plus per-website settings.

Our mic not working checklist is ordered exactly this way — browser gate first because it’s a two-click fix, OS gate second.

What “Allow” actually grants

A click on Allow grants the origin (the full https://mictest.tolerence.net address, not the whole domain, and certainly not the internet) the ability to start a capture while a tab is open. In return the browser promises three things:

• A visible indicator — a red recording dot or mic icon on the tab and in the browser UI, shown for as long as capture runs. Pages can’t suppress it.
• Capture bounded to the page’s lifetime — close or navigate the tab and the stream dies. No site can keep listening after the tab is gone.
• Revocability — lock icon → permissions → block/ask removes access on next load and kills any live capture.

Why device names are hidden at first

enumerateDevices — the API behind our picker — returns your inputs immediately, but with the labels blanked until the site holds an active grant. Otherwise a site could fingerprint you from your hardware list (“HD Webcam C920 + Yeti Stereo + AirPods” is nearly unique). It’s the same reason the picker refreshes itself after you allow: that second look is the first honest look.

What this site does with the permission

Everything the tester does happens in an in-page audio graph: stream → analyser (meter + waveform) → optional recorder → local blob. There is no upload step because there is no upload endpoint — the site is static files served by Cloudflare Workers; posting audio somewhere would require infrastructure that doesn’t exist here. You can verify it yourself: open DevTools’ Network tab while you talk — the only requests are static assets and ads. Or load the page, pull the network cable, and run the whole test offline.

Your recording lives in one tab’s memory as a blob URL. Download it if you want to keep it; close the tab and it’s gone — no server ever saw it, which is the strongest privacy guarantee a tool like this can make.

How to audit yourself

• Chrome/Edge: Settings → Privacy and security → Site settings → Microphone — shows every origin currently allowed or blocked.
• Firefox: Settings → Privacy & Security → Permissions → Microphone → Settings.
• Safari: Settings → Websites → Microphone — per-site Allow/Ask/Deny plus the default for new sites.
• OS level: macOS Privacy & Security → Microphone and Windows Settings → Privacy → Microphone show which apps hold the hardware gate — worth a glance after any OS upgrade, which is when grants tend to silently reset.

Frequently asked questions

Can a website listen to my mic without me knowing?

Not through the front door. Capture requires an explicit per-site grant, and while a site holds the mic the browser shows a persistent indicator — a red dot or mic icon on the tab and in the address bar — that no page can hide or fake. Closing the tab ends the capture. Exploits that bypass this are browser bugs and get patched; the permission model itself is solid.

Why did the site see my device names only after I clicked Allow?

Enumerating real device names ('USB Audio CODEC', your headset model) would itself leak identifying information, so browsers blank them until the site holds an active mic grant. That's why the picker shows 'Microphone 1/2/3' before you allow and real names after — it's the fingerprinting defense working, not a bug.

Is the mic permission permanent once I click Allow?

It depends on the browser and what you clicked. Chrome remembers Allow per origin until you revoke it (lock icon → Site settings, or Settings → Privacy → Site settings → Microphone). Firefox's prompt can be one-session or persistent depending on the checkbox. Safari typically asks each time for non-granted sites. Revoking always takes effect on next reload — a live capture is dropped too.

What's the difference between the browser prompt and the OS prompt?

They're two independent gates. The OS decides whether the *browser application* may use the mic at all (macOS Privacy & Security → Microphone; Windows Settings → Privacy → Microphone). The browser then decides which *websites* may use it. Both must say yes — an OS-level 'no' makes every site fail with no prompt at all, which confuses people constantly.

Why does the mic need HTTPS?

Microphone capture is a 'powerful feature' in spec terms, so it's only exposed on secure contexts: https:// pages, localhost, and file:// in some browsers. An http:// site literally doesn't have the getUserMedia API — which is why the tester checks the context before even trying.

What can this site see about my mic?

After you allow: the device label, its negotiated sample rate and channel count, the processing flags, and the live audio — which stays in the page. Before you allow: nothing but a count of generic 'audioinput' devices. We can't see device names, we can't capture a single sample, and we can't tell a USB mic from a built-in until you say yes.