Check the second gate when chrome microphone permission not working persists

You granted the microphone, the toggle says On, and the extension still hears nothing, so the natural verdict is that the app is broken. Before you reach for that verdict, know that Chrome keeps two independent gates: one belongs to the extension itself, and the other belongs to the page you are looking at. Both must be open before audio can flow, and each one fails in a slightly different way. This is why a chrome microphone permission not working situation can persist while the permission screen cheerfully shows permission granted: the switch you flipped is only half of the circuit. Naming which gate is closed tells you exactly which toggle to flip, and it converts the whole problem from guesswork into a thirty-second repair.

The extension-level gate is the one most people know about. When an extension wants to hear you, it usually requests microphone access through its own options or setup flow, and Chrome asks you to confirm that request once. Once granted, it stays granted for the extension in that profile, which is why this gate rarely causes trouble after the first install. It can close again, though, when a profile is reset, when the extension is reinstalled from a different source, or when Chrome decides a permission is stale after a major version change. The tell is that the extension's own status panel may report that it is listening while nothing arrives, because the extension believes it has access while the transport beneath it does not.

The page-level gate is the one that gets forgotten, and it is the usual villain in this story. Each origin, such as chatgpt.com or a docs site, holds its own microphone permission in Chrome, separate from the extension's grant, and the page must have its own permission for the audio to be delivered to the browser. News of the two gates matters because fixing the wrong one produces zero change: toggling the page permission when the extension was the blocked one, or reinstalling the tool when the page was blocked, both feel like the fix failed. When a microphone stops working, name both gates before touching either of them.

The signature symptom of the double-gate problem is a frozen meter. You press the capture key, the extension shows its listening state, and the waveform or level meter in the extension's panel does not move at all. A meter that moves but transcribes nonsense points at audio quality or language settings, while a meter that never moves points always at permission or input routing. This one observation saves you minutes, because it splits the whole problem space in half before you touch any setting. If the meter is dead, you are hunting permission, not vocabulary, and the hunt is short once you know the two gates.

The quickest way to distinguish which gate is closed is to test the extension on a page you fully control, such as its own options page. Open the extension settings, click the test or listen control there, and speak. If the meter moves on that page, the extension has its permission and its audio pipe, so the closed gate is on the website you were just using. If the meter stays dead even on the extension's own page, the issue lives at the extension level or deeper, in the operating system's choice of input device. This single comparison is the highest-value move in the whole workflow, because it tells you which checkbox to open before you go looking.

A third layer, the operating system, sometimes mimics the permission problem. Windows and macOS both have system-level microphone settings, and a headset plugged in over Bluetooth can silently become the default input while your laptop's built-in array sits on the bench. Chrome's permission can be green while the device it thinks it is using is a mute or missing one. If both Chrome gates look open and the meter still will not twitch, check the system input device and switch to a different microphone before you blame the extension, because the fix there is a device change, not a permission change.

When the extension's own test works but the site stays silent, walk to the second gate. Type chrome://settings/content/microphone into the address bar to land directly on Chrome's microphone settings, and you will see the list of sites allowed to use your microphone, plus the default behavior for everyone else. Most sites dictate correctly when they appear under Allowed, so find your target site in the list, and if it sits under Blocked or is absent while the global behavior is set to ask, you have found the gate. The subtlety is that a site can be missing from the list entirely, which Chrome treats as a fresh origin that needs to ask, and no prompt appears if the page believes it was already granted.

Why does the page believe it was granted? Because the two records can drift. The page remembers a granted permission in its own session, while Chrome's site-content list was reset by clearing browsing data or by a cookie cleanup, leaving the page thinking it holds a pass that the browser has quietly revoked. When this happens the dictation loop is a phantom: the site never re-requests, so nothing prompts, and the meter stays flat. The fix is to click the site icon in the address bar, open the permission panel, and choose Allow under microphone, or to toggle the setting off and on to force a fresh request from the page, which usually takes less than a minute to complete.

Set the global default thoughtfully while you are in the panel. The push-to-ask default is the privacy-friendly setting, but it means every new site you dictate on needs a one-time click, so many users prefer to allow the handful of sites they use daily and keep the default on ask for everything else. If you work across many origins, a middle path is allowing microphone for the five or six tools you regularly talk into and letting a quick site-panel click handle the rest. The goal is not zero prompts; it is a short, predictable list of sites where dictation always works and a fast recovery when a new one shows up.

The second recurring pattern is the stale lease, and it deserves its own section because the permission screens look perfect while everything is wrong. Chrome grants the microphone to one page at a time, and that page keeps a loose hold on the device until it explicitly releases it. If a tab opened a capture session earlier, a video call, a voice memo, a previous dictation attempt, and then failed to hand the stream over cleanly, Chrome can treat the device as busy while showing no visible recording icon to the user. Your new dictation request queues politely or fails silently, and the meter appears dead even though every permission setting is lit up correctly.

Detect the lease by watching Chrome's own indicator. When a page holds the microphone, a small recording icon appears in the tab strip for that tab, and Chrome shows which tab is capturing when you hover or open the site information. Close or reload that tab and the lease drops, which is the fastest cure. Some pages hold a lease without showing the icon at all, which happens when a MediaStream object was kept in memory after the interface closed, and in that case the only reliable fix is reloading the page that was involved, or in extreme cases restarting Chrome, since a frozen renderer can hold the device hostage much longer than the UI admits.

Once the lease is cleared, finish the job with a clean handoff. Close any tab that shows recording before you start dictating, or use a single dedicated tab for dictation instead of spreading attempts across many. If you are a power user who leaves a video call open in one window and dictates in another, note that the call legitimately wins the microphone, and dictation on other tabs will be rejected until the call mutes or ends. That behavior looks like the permission problem but is actually resource contention, and the fix is scheduling, not settings. The same lease can be held by a page you closed many tabs ago, so when a stubborn site keeps failing, restart the browser once, which releases every parked lease at once, and then retry dictation.

After any change, run the one-minute verification instead of trusting the screens. Click the site icon in the address bar, open the permission panel, and confirm that microphone shows Allowed for this specific origin. Then press your capture key, speak three seconds of clear speech, and watch two things: the meter in the extension and the recording indicator on the page. If the meter moves and the indicator lights, both gates are open, the lease is free, and your problem is solved. If the meter moves but the site indicator does not, the extension is capturing but the page is not receiving, which points at a content script or page reload issue rather than permission.

Now run the same test in a second environment to prove the diagnosis. Open a fresh tab on a different allowed site and speak once more; if dictation works there, the original page had a site-specific fault, and a reload of that page is the remaining step. If dictation fails everywhere, the problem is in the extension or the system device, and you should run the extension's own test panel, then switch the input device in your operating system. This two-step isolation is what takes a mystery and reduces it to one of three buckets, and each bucket has exactly one fix, which is a far better trade than reinstalling the extension and hoping.

Keep the verification results in mind for next time. Most people who solve this once find it is a two-minute recurring chore: a cookie cleanup, a laptop sleep, a new site, each quietly closing one of the gates. The durable habit is a ten-second glance at the site icon before you dictate for the first time on any site, and ten seconds after any system change. A permission problem you can name is a permission problem you can fix, and with both gates mapped, the dead mic loses its mystery for good. Write the two gates on a sticky note the first week: site permission first, then mic device, and you will stop turning circles between settings pages.