Technology & privacy
How system-wide dictation actually works on macOS
There are no plugins and no integrations. A dictation app asks macOS for one permission and then types, and the receiving application cannot tell the difference.
Last updated
The global shortcut
A keyboard shortcut belongs to whichever app is frontmost, unless it is registered as a global one with the system. A dictation app does the latter, which is why it works from any application including full-screen ones.
It is also why shortcut conflicts are the single most common reason dictation appears broken. Two apps can both claim a combination, and the one that registered first wins. If a shortcut does nothing, it is almost always taken — change it before assuming anything is wrong. See choosing a dictation shortcut.
Accessibility permission, and why it looks alarming
This is the part that makes people hesitate, reasonably. macOS asks you to grant an app access under Privacy & Security → Accessibility, and the wording implies the app can control your computer.
It can, in the sense that this is the permission governing synthetic input — one application generating keystrokes or events that another receives. There is no narrower permission for "may type text into other apps but nothing else". Apple has not split it, so a dictation app asks for the whole thing.
One practical note: after granting the permission, quit and relaunch the app. macOS does not always apply a newly granted permission to a running process, and this accounts for a large share of "I granted it and nothing happened".
Getting text into the other application
Two mechanisms, and good apps use both depending on the situation.
| Method | How it works | When it is used |
|---|---|---|
| Synthetic keystrokes | The app generates key events; the receiving app sees them as typing | Short passages. Most faithful to real typing |
| Clipboard and paste | The text is put on the clipboard and a paste is issued | Long passages, and apps that handle input in their own way |
Synthesising four hundred individual key events is slow and, in applications that do their own input handling, unreliable — characters arrive out of order or get dropped. A paste is one operation and is far more robust.
Why there is no list of supported apps
Because the receiving application is not involved. Slack does not know it is receiving dictation; it receives keystrokes. Word does not know. The browser does not know, which is why web apps work with no extension.
Three consequences worth stating:
- Nothing needs to be installed per application. No plugin, no add-in, no extension.
- Nothing breaks when an app updates. An integration would; keystrokes do not.
- New apps work automatically. An application released tomorrow supports dictation on the day it ships, without anyone doing anything.
Where it does not work, and why that is correct
| Where | Why |
|---|---|
| Password and secure text fields | macOS deliberately blocks synthetic input into them. This is a protection working as designed |
| Some virtual machines and remote desktops | The guest usually receives keystrokes normally, but it depends on how the client handles input |
| A few apps with custom text engines | Rare. Mostly older creative software that draws its own fields |
| Anywhere the cursor is not | Not a limitation — the text goes where the insertion point is, and if there is not one, nowhere |
The first row deserves emphasis: a dictation app that could type into a password field would be a security problem. Its inability to do so is a feature of macOS, not a gap in the app.
The full path, end to end
- You press the global shortcut. macOS delivers the event to the dictation app regardless of what is frontmost.
- The app requests the microphone. This needed its own permission the first time — separate from accessibility.
- Audio is captured while the shortcut is held, or until you tap again if the microphone is latched.
- Voice activity detection trims the silence at each end.
- The speech model, on your disk, produces text.
- Your vocabulary corrections are applied and any rewriting step runs.
- The text is inserted through the input layer, by keystrokes or by paste.
- The clipboard is restored if it was used.
- A copy is written to a local history on your disk.
Two permissions, one shortcut, no integrations, and nothing on the network in normal use.
Questions
Why does dictation need accessibility permission?
Because inserting text into another application is synthetic input, and that is precisely what the accessibility permission governs on macOS. There is no narrower permission for text insertion alone.
Is it safe to grant accessibility permission?
It is a genuine trust decision. Anything with that permission could do more than type. Grant it to signed, notarised software whose publisher you can identify, revoke it in one click if you change your mind, and watch the app's network activity if you want to verify its behaviour.
Why did dictation stop working after I granted the permission?
Quit and relaunch the app. macOS does not reliably apply a newly granted permission to an already-running process.
Why does my clipboard sometimes change?
Long passages are inserted by putting the text on the clipboard and issuing a paste, because synthesising hundreds of keystrokes is slow and unreliable in some apps. A well-behaved dictation app restores your previous clipboard contents immediately afterwards.
Does it work in full-screen apps?
Yes. A global shortcut is registered with the system rather than with a window, so it fires regardless of which app is frontmost or whether it is full screen.