Apple’s own troubleshooting page for this — “If Dictation on Mac doesn’t work as expected” — already covers the standard checklist: turn Dictation on in Keyboard settings, pick the right language, use the correct shortcut, check the microphone, and confirm you have an internet connection if the language needs one. If Dictation is simply off, muted, or set to the wrong language, that page fixes it faster than anything below.
What that page does not cover is the part that actually generates search traffic — people asking why Dictation fails specifically in Terminal, in Chrome, or in Google Docs, and not everywhere else. It also doesn’t mention that a “quick fix” terminal command circulating for this problem targets processes that, on a working Mac, usually aren’t even running when you type it.
What Apple already tells you to check
Before anything below, run through Apple’s own list once:
- Dictation is turned on under System Settings > Keyboard > Dictation, with the correct language and region selected.
- You’re using the shortcut actually assigned to it — the default is a function-key press or a customizable combination (Apple’s own example is Option-Z), not necessarily what an old article or muscle memory expects.
- If there’s no built-in microphone, an external one is connected and selected in Sound or Keyboard settings, with its input volume turned up.
- Nothing is physically blocking the microphone, and you’re not talking over background noise.
- You have an internet connection, unless the language you’ve selected supports on-device processing — Keyboard settings state whether your voice is processed on the Mac or sent to Siri’s servers.
One more official detail worth knowing before you assume Dictation crashed: it stops automatically after 30 seconds of silence. That’s documented behavior, not a bug.
Dictation depends on where you’re typing
Search autocomplete for this topic splits cleanly by app — “dictation not working in terminal,” “in chrome,” “in google docs.” That pattern exists because Dictation doesn’t talk to every text field the same way.
Terminal has its own kill switch
Terminal has a menu item — Terminal > Secure Keyboard Entry — that Apple’s own guide describes as preventing “other apps on your computer or the network from detecting and recording what you type in Terminal.” Apple’s instructions add that before turning it on, you should make sure other apps don’t need keystrokes from Terminal — a hint that its effect isn’t scoped to Terminal alone.
The setting is a real, readable preference key, and its effect is not scoped to Terminal’s own window:
defaults read com.apple.Terminal SecureKeyboardEntryA result of 1 means it’s on. Apple’s archived developer note on the underlying mechanism, TN2150, documents that the feature blocks keyboard events from being intercepted by other processes system-wide — it doesn’t name Dictation specifically, since the note predates the current Dictation architecture and Apple stopped updating it. Apple Developer Forums threads and a public terminal-emulator discussion describe the practical result: with Secure Keyboard Entry on, Dictation and other system input methods stop receiving text in that window. If Dictation fails only in Terminal, that toggle — not a broken speech service — is the first thing to check.
Google Docs renders its own text, not a standard field
Since May 2021, Google Docs draws its editing surface with canvas-based rendering rather than ordinary HTML text elements — Google’s own announcement warned it would affect Chrome extensions that expected a standard text field to attach to. Google added a hidden accessibility layer alongside the canvas for screen readers, but that announcement is specifically about assistive technology and extension APIs; it says nothing about Dictation, and no Apple or Google document ties the two together directly. The plausible mechanism — a non-standard rendering surface instead of a normal editable field — is consistent with reports of Dictation behaving inconsistently there, but that’s an inference, not a confirmed cause.
The killall command that circulates for this — and why it’s usually a no-op
A command that shows up repeatedly in Dictation troubleshooting content looks like this:
killall -9 DictationIM com.apple.SpeechRecognitionCore.speechrecognitiond com.apple.SpeechRecognitionCore.brokerdThe three names are real. On macOS 26.5.2, DictationIM is the actual executable inside /System/Library/Input Methods/DictationIM.app, and com.apple.SpeechRecognitionCore.brokerd / com.apple.SpeechRecognitionCore.speechrecognitiond are the real binary names of the XPC services bundled inside the SpeechRecognitionCore framework. So the command isn’t nonsense syntax — but killall only kills processes that are already running, and these three are launched on demand, not kept alive in the background. Checking a running system with pgrep -fl DictationIM and pgrep -fl SpeechRecognitionCore while Dictation is idle returns nothing for either. Running killall against a process name that isn’t currently loaded produces exactly one outcome:
No matching processes belonging to you were foundThat’s the message for each of the three names, every time you run the command while Dictation isn’t actively in use — which, for most people troubleshooting a Dictation problem, is the normal state. The command doesn’t error out or do anything harmful; it just does nothing, and the appearance of a Terminal command produces a false sense that something was fixed.
On Apple silicon, two “advanced” steps don’t apply
Deeper troubleshooting lists for Dictation and other system glitches tend to include resetting NVRAM and booting into Safe Mode. Both are described as if there’s one procedure — there isn’t, and treating them as universal is itself a source of wasted time.
| Step | Apple silicon Macs | Intel Macs |
|---|---|---|
| NVRAM/PRAM reset | Doesn’t apply and isn’t needed, per Apple’s NVRAM support documentation — the firmware handles this automatically. | Restart holding Option-Command-P-R until the Mac restarts a second time. |
| Safe Mode | Shut down completely, hold the power button until “Loading startup options” appears, select a volume, hold Shift, then click Continue in Safe Mode. | Restart or turn on while holding Shift until the login window appears. |
Following the Intel Safe Mode steps on an Apple silicon Mac — hold Shift at restart — does not produce Safe Mode at all; the Mac just starts normally. Apple’s Safe Mode guide lists both procedures separately for exactly this reason.
What macOS actually stores about your Dictation setup
Dictation’s state lives in a preference domain that isn’t documented in any Apple user guide:
defaults read com.apple.speech.recognition.AppleSpeechRecognition.prefsThat domain holds keys including DictationIMMicrophoneIdentifier (which input device Dictation is bound to), DictationIMPreferredLanguageIdentifiers (the language list, in priority order), and DictationIMUseOnlyOfflineDictation (whether it’s forced to on-device processing only). None of that is exposed anywhere in System Settings beyond a single language picker and an on/off toggle. If Dictation is stuck on a microphone you no longer use, or locked to offline mode after a language pack changed, this is the only place that shows it — reading the domain is harmless; there’s no supported way to edit individual keys here, and doing so isn’t something this article recommends.
When none of this fixes it
If Dictation is enabled, the microphone works in other apps, Secure Keyboard Entry is off, and you’re not on a canvas-rendered page — and it still won’t produce text — that’s past the point where Terminal commands help. Apple Support or an Apple Store appointment is a better use of time at that stage than repeating the same restart-and-hope cycle.