Quick answer
What this guide helps you determine
Change a blocked site permission and understand the difference between browser and operating-system access.
Begin with the observable browser result, repeat it under the same conditions, and change one connection, setting or application at a time. A browser result narrows likely causes but does not certify hardware or decide a repair.
Scope of this check
Microphone access requires a secure origin, a site-level browser decision and operating-system permission for the browser application. Grant it only for the correct domain and only when a microphone task is expected.
Step-by-step method
- Confirm the address is the intended HTTPS site, click Start and choose Allow in the browser prompt. If you previously blocked it, use the address-bar site controls to change the microphone decision and reload.
- Open operating-system privacy settings and verify microphone access for desktop applications or the specific browser, depending on the platform. Check physical mute and select the correct input after permission exposes labels.
- Run a short meter test, press Stop and verify the microphone indicator disappears. Remove the site permission afterward if you do not want it remembered.
What to check first
Use these checkpoints to keep the comparison focused. Record the visible behavior rather than assigning a fault label too early.
- Check the address-bar permission icon
- Review OS app privacy settings
- Reload and click Start again
How to read what you see
| Observation | What it can suggest | Useful next check |
|---|---|---|
| Prompt appears after Start | No stored decision prevented an origin-specific request. | Choose deliberately and verify the meter. |
| Browser says allowed but OS says blocked | The operating-system layer overrides site permission. | Enable access for the browser or use another permitted app. |
| Prompt never returns after a prior block | The browser stored the decision. | Reset this site’s microphone permission and reload. |
Common mistakes to avoid
- Do not allow microphone access on a look-alike domain.
- Do not choose a private meeting input by guess when labels are available.
- Do not leave permissions broader than needed.
Build evidence another person can use
Write down the exact action, visible result and whether it repeats. Include the browser family, operating-system family, connection type and the single comparison that changed the result. Quote the observation directly—for example, “Prompt appears after Start”—then add where it occurred and which comparison changed it.
Change one condition per comparison and return settings that have no effect. Follow model-specific manufacturer instructions before firmware changes, cleaning, disassembly or warranty action.
When to seek qualified support
If the same problem remains in multiple applications and on another compatible connection or computer, collect the repeatable observations and contact the manufacturer or a qualified technician. Stop using equipment that is physically damaged, unusually hot, wet, sparking or unsafe. Device Test Bench cannot inspect electrical condition or make a repair decision.
Privacy during testing
Our public tests process key events, pointer values, media streams and controller input locally. Do not send private recordings, complete typed text or device identifiers when asking for help. A short description of the behavior, browser and page URL is normally enough.
Questions readers ask
Why does permission need HTTPS?
Secure contexts reduce the risk that network tampering can gain access to powerful media APIs.
Can I test without allowing the microphone?
You can review compatibility and instructions, but live audio level requires access to an input stream.
Primary technical references
The following specifications define the browser APIs discussed in this guide. They are primary web-platform references, not product repair manuals.