#Three features, three different failures
Three separate things get called dictation on a Mac, and they fail for unrelated reasons. Naming the broken one first removes most of the guesswork.
- macOS keyboard Dictation. The system feature started with a keyboard shortcut. macOS captures the audio itself and inserts text wherever the keyboard focus happens to be. Settings live in System Settings > Keyboard > Dictation.
- Google Docs voice typing. A Google Docs feature, not a macOS one: Tools > Voice typing, which Google documents as working in Chrome browsers only. It records through the browser microphone, so it depends on permissions Chrome has to hold.
- Voice Control. An accessibility feature under System Settings > Accessibility > Voice Control that both types and takes spoken commands. Different engine, different settings, different failure mode.
The consequence that saves the most time: keyboard Dictation does not route audio through Chrome. The system does the listening, so a copy of Chrome that was never granted microphone access can still receive dictated words, and granting that access changes nothing about it. That same checkbox is close to the entire answer for voice typing in Docs. Two problems, one settings pane, opposite advice.
#Seven checks, in the order that finds it fastest
Run them in order. Each one either finds the fault or rules out a whole class of them.
1. Prove where it breaks
Open Notes, click into a note, press the dictation shortcut and say a sentence. Then do the same in an ordinary text box on a web page in Chrome: a comment field, or a search box on a normal site. Skip the address bar as a test, because Chrome draws that field itself and it does not behave like a field on a page. Text in Notes but not in Chrome sends you to the Google Docs section and to checks 5 and 6. Nothing anywhere sends you to checks 2, 3, 4 and 7.
2. Turn Dictation on, and learn its real shortcut
System Settings > Keyboard > Dictation. The toggle at the top has to be on, and macOS asks for confirmation the first time it is switched on. Below it sits a Shortcut popup, and whatever it says is the only shortcut that works: on keyboards with a dedicated microphone key, that key; otherwise a double press of a modifier such as Control. A double press means two taps in quick succession, and a slow second tap does nothing at all. If the popup reads Off, that is the whole bug.
3. Check what the globe key is set to do
Still in System Settings > Keyboard, a popup controls what the globe key does: change the input source, show emoji and symbols, start dictation, or nothing. Anyone expecting the globe key to start dictation and getting the emoji picker instead has just found the answer. macOS also stores keyboard behaviour per keyboard, so an external keyboard can carry a different setting than the built-in one, and the Modifier Keys sheet has its own keyboard picker for exactly that reason.
4. Re-add the language, and pin the microphone source
The Dictation pane lists the languages it will recognise. Removing a language and adding it back forces macOS to fetch the recognition assets again, which matters because a download that never finished leaves dictation in its worst state: the indicator appears, the machine listens, no text arrives. The same pane has a Microphone Source popup. Automatic is convenient right up to the moment it picks a device nobody is speaking into, so set it explicitly while testing.
5. Give Chrome the microphone, then quit it properly
System Settings > Privacy & Security > Microphone, and switch Google Chrome on. macOS offers to quit and reopen the app; take the offer. A running app keeps the permission answer it launched with, so a Chrome that was denied earlier stays denied until it is fully quit with Command-Q, not merely closed with the red window button. This is the fix for Docs voice typing, for Meet, and for any site that asks to record. It does nothing for keyboard dictation.
6. Clear the per-site block inside Chrome
Chrome keeps its own microphone permission per site, on top of the macOS one. Open chrome://settings/content/microphone, confirm the default is set to ask, and read the list of sites not allowed to use the microphone. A site lands on that list permanently after one accidental Block and will never prompt again. On the page itself, the icon at the left of the address bar opens the same setting for that site. One more constraint worth knowing: browsers hand out the microphone only on secure pages, so a site served over plain HTTP gets nothing regardless of what has been granted.
7. Rule out a restriction, then restart
Screen Time can switch dictation off entirely under Content & Privacy, which is easy to miss on a shared or family Mac. A work Mac can carry the same restriction from a configuration profile, and System Settings > General > Device Management shows whether one is installed. If nothing is restricted, log out and back in, or restart. Speech services can wedge after a macOS update, and a restart is the cheapest way to find out whether that is all that happened. If dictation stopped on the day of an update, run this check early rather than last.
#Google Docs is the hard case, and canvas is why
Docs earns its own section because the checks above do not touch it. Since 2021, Google Docs has rendered documents into a canvas element instead of ordinary HTML text nodes. There is no editable text node in the document body for macOS to insert into, so system dictation can be listening perfectly and still put nothing on the page.
One test proves it. In the same document, dictate into the document title at the top, or into a comment. Both are ordinary form fields, and both accept dictated text. If words land there and nothing lands in the body, the canvas is the reason: not the microphone, not the shortcut, not Chrome’s permissions.
- Turn on screen reader support. Command-Option-Z toggles it, or Tools > Accessibility settings. It is the switch Google documents for making Docs work with assistive technology, and it changes how the editor exposes its text.
- Use Docs’ own voice typing. Tools > Voice typing, or Command-Shift-S. It is built for the canvas editor, so it types where system dictation cannot. Google states it works in Chrome browsers only, and recognition runs on Google’s servers rather than on the Mac, which is a real difference if the document is sensitive.
- Dictate elsewhere and paste. Covered below, and it is the option that never surprises anyone.
The same logic applies to any web app that draws its own editor instead of using a text field. Canvas-based editors, and some code editors that run in the browser, refuse system dictation for the same structural reason. The test never changes: try a plain field on the same page and see whether the words land there.
#When the microphone really is the problem
If nothing works anywhere, stop touching Chrome and check that the Mac can hear at all. System Settings > Sound > Input lists the input devices and shows a live level meter. Speak at it. If the meter does not move, no browser setting is going to help.
- The wrong input device. A dock, an audio interface or a webcam microphone can be selected and pointed at the wrong room. Switch to the built-in microphone to test.
- AirPods and other Bluetooth headsets. Using them as an input puts them into headset mode, and a set that drifted to a phone mid-sentence leaves macOS listening to a device that is no longer there. Reselect the input.
- Another app holding it. A meeting app left running in the background can keep the microphone busy. macOS shows an orange dot near the menu bar whenever the microphone is live, and Control Center names the app using it.
- Input volume at zero. The input slider is stored per device and persists quietly across reconnects.
In Chrome specifically, a tab that is recording shows an indicator on the tab itself. That is a fast way to tell the difference between a browser that got the microphone and produced nothing useful, and a browser that never asked for it.
#Voice Control fails in browsers for a different reason
A good share of searches about dictation in Chrome turn out to be about Voice Control, which is a separate accessibility feature with separate settings. It types by pushing text into the focused field, so straight dictation with it usually does land in a browser. The editing and navigation commands are the part that struggles: selecting the last word, or correcting a phrase, relies on an app publishing its text through the macOS accessibility interface, and a browser drawing its own web content does not always expose it in the form those commands expect. The result is a feature that types fine and then refuses to edit what it typed.
Two practical notes. Voice Control has to be switched on under System Settings > Accessibility > Voice Control, and it downloads its own assets on first use, so the first attempt on a new Mac can look broken while it is still fetching them. And if keyboard dictation started misbehaving on the same day someone experimented with Voice Control, switch Voice Control off and test keyboard dictation again before chasing anything else.
#The fallback that always works
When a web app refuses dictated text, the reliable route is to put the words somewhere that accepts them and move them across. Dictate into Notes, TextEdit or Stickies, select all with Command-A, copy with Command-C, click into the browser field and paste with Command-V. Command-Shift-V pastes without the source formatting, which is usually what a document or a form wants.
It is clumsy, and it works in every case on this page, canvas editors included. The thing to watch is the clipboard itself: macOS keeps one item, so a second dictated paragraph overwrites the first the moment it is copied. Clipboard history on Mac covers what the system retains and what it quietly drops, and how to copy on Mac collects the shortcuts, including the ones that behave differently inside a browser.
If dictation broke right after a system update rather than after a browser change, the OS version is worth a look on its own; the macOS 26 Tahoe write-up covers what changed and where settings moved.
#Questions people ask
Why is there no sound coming out of Chrome on a Mac?
That is the output side, and it is unrelated to dictation. Check three things in order: the tab, since Chrome can mute a single tab from its right-click menu; the site setting at chrome://settings/content/sound; and System Settings > Sound > Output, where a Mac still pointed at a Bluetooth speaker in another room looks exactly like a browser with broken audio.
Does Mac dictation need an internet connection?
For supported languages it can run on the Mac once the language assets have been downloaded, which is why the first attempt after adding a language often needs a network and later ones do not. Google Docs voice typing is the opposite case: recognition happens on Google’s servers, so it needs a connection every time.
#What this means for the notch
Everything above is a routing problem: the words exist and the field will not take them. A notch app does not fix Chrome, but it changes where the text starts. NotchBay runs dictation through Apple’s SpeechAnalyzer on macOS 26, keeps the audio on the Mac, and leaves the transcript ready to copy or to insert at the cursor, so an editor that refuses system insertion still accepts a paste. It requires macOS 26 and is designed for a MacBook with a notch; on a Mac without one it runs as a small floating pill instead. That is a different starting point, not a fix for a canvas editor.
