Dictation is not working on your Mac

Ordered by how often each cause turns out to be the real one, rather than by how easy it is to write about. The last two are Mac-specific traps that almost nothing on the internet mentions, because you only meet them if you have written this kind of software.

1. The microphone is producing silence, not quiet audio

The commonest real cause, and it looks like a recognition problem. Two ways it happens:

• Bluetooth headphones in listening mode. AirPods and most headsets sit in an output-only Bluetooth profile that carries no microphone. macOS still reports a valid input device with a plausible sample rate, and recording produces a buffer of exact zeros. Everything looks fine; nothing was heard.
• Audio interfaces and virtual devices. On a multichannel or aggregate device — a mixer, BlackHole, Loopback, a meeting app’s virtual mic — the software may be reading a channel your microphone is not wired to, and that channel is silent.

Test: open System Settings → Sound → Input and watch the level meter while you speak. No movement means the device, not the software. Switch to the built-in microphone and try again before changing anything else.

2. Permission was granted to a different copy of the app

macOS binds Microphone, Accessibility and Input Monitoring permissions to the app’s signature, not its name. Rebuild it, re-sign it, or replace it with a copy that was signed differently, and every permission is silently revoked — the app is still listed in System Settings, still ticked, and still denied.

Fix: remove the app from the relevant list in System Settings → Privacy & Security, then add it again. Toggling the switch is often not enough; delete the entry.

3. Voice Control is holding the audio

Rarely written about and genuinely confusing when it happens. Voice Control (System Settings → Accessibility) takes the input pipeline in a way that can leave other dictation tools with nothing, and it can be left on by an accessibility shortcut nobody remembers pressing.

Check: Accessibility → Voice Control. If it is on and you did not turn it on, that is your answer.

4. Secure input is on, so the text is blocked rather than missing

This one is invisible and it explains the strangest reports: dictation works, the app says it succeeded, and nothing appears.

When any application holds “secure input” — a password field, a password manager, some terminal emulators, and sometimes a background app that never let go — macOS blocks synthetic keystrokes system-wide. Dictation tools that insert text by simulating a paste are silently refused. Nothing errors.

Find the culprit:

ioreg -l -w 0 | grep SecureInput

The kCGSSessionSecureInputPID value is the process id holding it. Look it up with ps -p <pid>. Quitting that app releases the hold; logging out always does.

5. It stops after about thirty seconds

That is Apple’s dictation ending the session after silence. There is no setting for it. If it stops while you are still talking, go back to cause 1 — the input has probably gone silent and the timeout is just what you noticed.

6. It does not work in one particular app

Chrome, Electron apps and some Java applications answer the accessibility system unreliably, which is where a lot of dictation software gets confused about whether a text field is focused. Try the same dictation in TextEdit. If it works there, the problem is the target app, not your Mac.