microphone · evidence-led troubleshooting

Chrome Microphone Permission Not Working

Chrome site permissions can block microphone access independently of the microphone hardware.

Reviewed 2026-08-114 diagnostic steps1 official sources

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 for DeviceOK and allow Microphone.

  2. 2

    In Chrome Settings > Privacy and security > Site settings > Microphone, verify the intended input and permission state.

  3. 3

    Also verify operating-system microphone access.

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

    Open the site permission control for DeviceOK and allow Microphone.

  2. 2

    In Chrome Settings > Privacy and security > Site settings > Microphone, verify the intended input and permission state.

  3. 3

    Also verify operating-system microphone access.

  4. 4

    Reload DeviceOK and run the microphone test again.

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

Use the passing DeviceOK test to narrow the problem to the specific app or settings layer.

If it also fails here

If DeviceOK also fails, step back to permissions, connection, OS configuration, and device-level troubleshooting.

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