How it works
Every dictation app implements some version of all three and picks per target field, usually in this order of preference.
The problem: applications were never designed for this
A text field in any application — a Word document, a Slack compose box, a browser form — belongs to that application. There is no standard operating-system API called 'insert text here', because operating systems were designed around the assumption that text arrives from a keyboard. A dictation app is, from the OS's point of view, an impostor keyboard, and everything in this article follows from that.
Method one: the accessibility back door
The cleanest route was built for a different purpose entirely. Every major OS ships an accessibility API so screen readers and assistive tools can inspect and manipulate other applications' interfaces. On macOS that's the Accessibility API: an app with permission can walk the UI tree of any window (AXUIElement), find the focused text field, and set its value or selected text directly. Windows has the equivalent in UI Automation's TextPattern.
Text inserted this way appears instantly, handles Unicode and emoji perfectly, and doesn't touch the clipboard. The costs are permission and cooperation: macOS gates the API behind the Accessibility prompt in Privacy & Security settings (which is why every Mac dictation app asks for it), and it only works on applications that expose their text fields properly to the accessibility tree. Native apps do. Many Electron apps, custom-drawn interfaces, terminals and games do not — or expose the field but refuse writes to it.
Method two: pretending to be a keyboard
The universal fallback is synthesised keystrokes: the app asks the OS to generate key events as if you typed them (CGEventPost on macOS, SendInput on Windows, XTestFakeKeyEvent on Linux X11). This works in essentially every application, because almost nothing refuses keyboard input — it is the lowest-common-denominator path.
It is also the lossy one. Character-by-character synthesis is slow enough that long dictations visibly type out; non-ASCII characters need dead-key gymnastics or per-layout mapping, which is why some apps mangle accented characters in certain fields; and anything that intercepts keystrokes — Vim modes, password managers, games with anti-cheat — can scramble the result. This is also the method behind the classic bug where dictated text loses its first characters: the app switched focus and started typing before the target application was ready.
Method three: the pasteboard trick
The third method is the pragmatic hack most modern apps use for long text: silently copy the dictated text to the system clipboard, send a synthesised Cmd+V / Ctrl+V keystroke, then restore the previous clipboard contents. It combines the speed and Unicode-safety of the clipboard with the near-universal compatibility of a keystroke.
You have probably caught it happening: your clipboard manager shows a flash of dictated text, or a paste of the wrong thing lands when timing goes wrong. Password fields refuse it (they block pasting by design), some remote-desktop and virtual-machine windows eat the paste, and apps that transform pasted content — rich-text editors that reformat on paste — can mangle the result. A well-engineered dictation app tries accessibility injection first, falls back to paste, and drops to raw keystrokes only when both fail.
Why Linux is the odd one out
On X11, the old Linux display system, everything above works much as on the Mac — including XTest keystroke injection and global hotkeys. Wayland, its modern replacement, deliberately removed the ability for one application to inject input into another or snoop global keystrokes: those capabilities were treated as security holes, because a keylogger is the same technology as a dictation app, differing only in intent.
The result is that Linux dictation apps have to work through newer, narrower channels: compositor-specific virtual-keyboard protocols (how wtype and ydotool operate), or desktop portals. This is why the Linux side of our ranking is thin, and why the open-source apps lead there — they can integrate at layers a sandboxed commercial app cannot.
What this explains about your daily experience
Nearly every quirk of dictation software is a fingerprint of one of these three methods. Text that types out visibly: keystrokes. Clipboard surprises: the paste trick. Apps that work everywhere except your terminal or a specific Electron app: accessibility injection with no usable fallback for that field. Password fields that refuse dictation entirely: all three methods blocked, correctly, by design.
It also explains the permission wall. Accessibility access, input monitoring and microphone permission are not bureaucratic box-ticking — they are the three capabilities the entire product is built from, and the reason a macOS update that resets them silently breaks dictation until you re-grant them.
References
- Apple — Accessibility API (AXUIElement) documentation — the macOS text-injection path
- Microsoft — UI Automation TextPattern — the Windows equivalent
- Wayland — input handling design notes — why global injection is intentionally absent
Frequently asked questions
Why does dictation lose the first word I say sometimes?
Usually focus timing: the app starts injecting keystrokes before the target field is ready to receive them, or the voice-activity detector clipped your first syllable. A slower start after pressing the hotkey fixes most cases.
Is the pasteboard trick safe?
Mostly — good apps restore your previous clipboard immediately. But anything sensitive in your clipboard is briefly replaced, and clipboard managers will record dictated text. Apps that default to accessibility injection avoid this.
Can a dictation app be a keylogger?
Technically the permissions overlap heavily, which is exactly why the OS gates them behind prompts. It's a reason to choose apps from vendors you trust and to prefer open-source options if you want to verify behaviour yourself.