DeviceOK
SearchDevice checks
Home / Fixes / Microphone Permission Denied

microphone · evidence-led troubleshooting

Microphone Permission Denied

Use a focused DeviceOK test first, then follow the evidence from browser/device state before changing drivers, firmware, or hardware.

Reviewed 2026-08-113 diagnostic steps2 official sources
Run Mic testSee fault tree ↓

What this symptom means

A permission failure can block perfectly healthy hardware. DeviceOK separates browser permission from whether the device exists and produces a usable signal.

Diagnostic principleSeparate detection, permission, selected input, signal level, routing and physical capture. A microphone can be listed by the OS while still producing no usable signal, and it can work in the browser while one app is misconfigured.

Fault tree

Microphone fault tree

Use the observation that best matches what you can reproduce. Do not treat every cause as equally likely.

1
Wrong input or routing

Evidence: A different microphone shows signal, or DeviceOK works while the affected app does not.

Next: Compare the selected input in the browser, operating system and affected app.

2
Permission/privacy block

Evidence: The device exists but access is denied, never prompts, or works in one context and not another.

Next: Check browser site permission and OS microphone privacy controls before reinstalling anything.

3
Mute/gain/input-stage problem

Evidence: The microphone is detected but the meter stays flat or is extremely quiet.

Next: Check physical mute, interface gain, OS input level and app input gain in that order.

4
Connection or endpoint failure

Evidence: The microphone is absent in DeviceOK and another trusted app, or reconnecting changes detection.

Next: Simplify the connection path: direct port, known-good cable, no dock, then official driver/firmware support.

Interpret the result

Evidence matrix

A test result is useful only if it changes the next troubleshooting branch.

ObservationWhat it supportsPrioritize next
Works normally in DeviceOKThe browser received a live audio stream from the selected input during this session.App selection, app permission, routing, processing or conferencing settings.
Detected but no signalAn endpoint exists, but detection alone does not prove the capsule/interface is passing audio.Mute, gain, wrong endpoint, interface channel, cable or hardware path.
Not detected anywhereThe problem is below the affected app layer.Connection, power, OS recognition, driver/firmware, then hardware.
Intermittent/static onlyThe path exists but signal integrity is unstable.Cable, connector, wireless interference, USB power, grounding or failing hardware.

Fast baseline

Rule out the simple causes first

  1. 1

    Open the site permission control and set Microphone to Allow.

  2. 2

    Check Windows/macOS privacy settings if the browser still reports denial.

  3. 3

    Reload the page after changing permission.

Full sequence

Work from reversible checks to invasive ones

Do not reinstall hardware drivers before checking the site/browser and operating-system privacy controls.

  1. 1

    Run DeviceOK Microphone Test again.

  2. 2

    If permission is granted but no input appears, continue with input selection, mute, cable/Bluetooth, and OS audio settings.

  3. 3

    If the microphone works here but not in another app, check that app's microphone selection.

Platform branches

Where the setting lives

Windows

  • Settings → Privacy & security → Microphone
  • System → Sound → Input device and input level
  • Device Manager only after detection/permission is checked

macOS

  • System Settings → Privacy & Security → Microphone
  • System Settings → Sound → Input
  • Check aggregate/multi-output audio only if you intentionally use Audio MIDI Setup

Browser

  • Use the lock/site-controls icon to confirm microphone access
  • Make sure the intended input is selected after reconnecting a headset/interface
  • Retest in a private/incognito window only to isolate extensions—not as a permanent fix
If it works in DeviceOK

If the matching DeviceOK test succeeds, prioritize the affected app, browser policy, operating-system setting, or configuration before assuming complete hardware failure.

If it also fails here

Failure in both DeviceOK and a second trusted app moves the fault below the original app layer. Compare the simplest direct connection and official diagnostic path before replacement.

Escalation threshold

When software troubleshooting has stopped being high value

  • Fails in DeviceOK and at least one other trusted app
  • Fails after a direct known-good cable/port path
  • Manufacturer diagnostics also report an input/interface fault
  • Physical damage, liquid exposure or connector damage is visible
Changed one variable?After permission is granted, rerun the relevant live test and confirm the device produces the expected signal/output. Retest under the same condition so the result is comparable.
Retest Mic test