The accessibility API does the work — the app sends text to whatever you are typing into

Dictation works across macOS because the accessibility API lets any app send text to any other app's text field, just as the keyboard does. You click in a field, press the hotkey, speak, and the words land in the app you chose. No special configuration for each app, no list of supported applications, no fallback to copy-paste — the system does the work and the app stays invisible.

How the text gets there

When you hold down the hotkey and start speaking, the app notes which field has focus and which app owns it. It stays connected to that field — if you start dictating and the window goes to the background, the text still lands in the field you picked at the start. The moment you let go of the key, the app sends the words to that field through the macOS accessibility API.

The accessibility API is the system layer that lets assistive software — screen readers, dictation tools, automation utilities — interact with applications in the same way a keyboard or trackpad does. A screen reader tells you what is on screen by querying the accessibility tree. A dictation app sends text to a field by posting to it through the same interface. From the application's perspective, the text appears through the normal input path, indistinguishable from typing or pasting.

If the accessibility API works, the text arrives instantly and in the right place. This is the normal case for native macOS applications and for most web applications, because they expose their text fields through the accessibility API.

If the accessibility API does not work — usually because the app has opted out of it or the text field is not standard — the app tries a synthetic paste. It puts the text on the clipboard, then sends a Paste command (Cmd+V) to the app, and then restores your clipboard to what it held before. This takes longer and requires that the app honours Paste, but it is transparent to you — you do not need to choose or configure anything.

Some applications block paste entirely, usually for security reasons: password fields, terminal applications, and some embedded editors. The app handles each case:

• Password fields usually support dictation through the accessibility API even if they block pasting, so text arrives through that path instead.
• Terminal applications see Paste rejected, and the app shows a helpful error with a link to the dedicated terminal how-to, which uses a different input method.
• Embedded editors (e.g., an editor inside a web app that implements its own text input) might support neither accessibility nor paste. This is rare and application-specific.

In almost all cases, this is completely transparent: you dictate, the text arrives, and you move on. The machinery of how it got there is hidden.

Setting up: How to dictate into a specific app

1. Open the app and click in the text field where you want words to land. This establishes focus. The app knows where to send the text.
2. Press and hold your dictation hotkey. (By default, ⌥ Space; you can change this in settings.) The app activates and the pill appears.
3. Speak the text. Talk as you would normally. The level meter shows the app is hearing you. Pauses and punctuation work as expected.
4. Let go of the key. Text arrives in the field you clicked in, instantly or via paste depending on what the app supports.

That is the whole workflow. No export-to-app, no copy-paste, no manual steps after dictation.

If the field does not have focus, the app's UI shows a message saying no field is selected. Click in a field and try again.

If you want text to land in a different place, click in that new field and dictate again. You can switch between apps, between windows, even between fields in the same app, and dictation will go to whichever field has focus.

Apps that work perfectly

• Native macOS applications: Mail, Notes, Messages, Slack, Terminal (via the dedicated terminal how-to), Xcode, Finder, Obsidian, Bear, and most Mac-native editors.
• Web browsers: Chrome, Safari, Firefox and other browsers, and web applications that use standard HTML text inputs or textareas (Gmail, Google Docs, GitHub, Twitter, etc.)
• Office suites: Microsoft Word and Excel, Apple Pages and Numbers, Google Sheets and Docs.
• IDEs and editors: VS Code, Sublime Text, Nova, JetBrains products.

If an app has a text field and you can click in it, dictation works.

Apps that need special handling

Terminal applications require a separate input method because they block paste. There is a dedicated how-to for terminal dictation that explains the workaround.

Password fields usually work through the accessibility API even though they block paste, so they just work — dictate into them the same way.

Custom embedded editors in web apps (e.g., some Markdown editors or code playgrounds) might not expose a standard text field. The app will show an error message. In these cases, copy the dictation from your history, switch to the editor, and paste it manually — or move your work to a standard text field for the dictation step. History keeps every dictation you make, so you can always go back and retrieve the words.

What you control

The field: You control where text lands by which field has focus. Click in different fields and dictate into them independently.

The length: There is no character limit per dictation. Speak for as long as you need; the text lands all at once when you release the key.

Your clipboard: Your clipboard is restored after a paste-based dictation, so if the app uses paste, your copied text is still there afterward.

The formatting: The app preserves your exact words. Punctuation and spacing are handled by the fixed post-processing chain; no model is asked to fix the sentence.

What the app controls (and why it matters)

The timing of the field lookup. The app looks up which field has focus at the moment you press the key, not when you let go. This means if you press the key in one app and a notification pops up in another, stealing focus, the text still lands in the app you intended. The field is locked in at key-down.

The clipboard backup and restore. When pasting is used, the app saves your clipboard before and restores it after, so your copied text is never lost. This happens invisibly.

The access to the accessibility API. You need to grant the app permission in System Settings → Privacy & Security → Accessibility. The first time you run it, the system prompts you. Once granted, the app can send text to any app that exposes its text fields.

Common questions about field targeting

Q: If I dictate into one app and another app takes focus, where does the text land? A: In the app you had focus in when you pressed the key. The field is locked in at key-down.

Q: Can I dictate into a minimized window? A: No. Focus follows the window hierarchy; if a window is minimized, it does not have focus. Click on the app in the Dock or use Command+Tab to bring it to the foreground, then dictate.

Q: What if the app is in the background? A: It is fine. If a window is backgrounded but visible, and you click in its text field, it has focus and dictation works. If the app is completely hidden (e.g., you switched to another workspace), click in the field to focus it first.

Q: Can text land in the right field if I am fast enough at switching apps? A: No, and that is the point of locking the field at key-down. Even if you are very quick, the field is already chosen the moment you press.

Why the accessibility API matters

The macOS accessibility API is the reason dictation can work in any app at all. Without it, dictation tools would need explicit support built into every application. Instead, the API provides a standard way for assistive software to interact with applications, and your dictation app uses that standard.

This is the same interface that powers screen readers and voice control software. When you grant the app permission in System Preferences, you are telling macOS that this app is allowed to use the assistive layer. After that, it can send text the same way a keyboard driver would.

Common workflows and which apps work best

Email: Dictating into email is one of the most common uses. Gmail, Apple Mail, Outlook, and most web-based email systems work perfectly — click in the compose field and dictate. The text arrives as if you had typed it.

Chat and messaging: Slack, Discord, iMessage and other chat apps are designed with focus management in mind, so dictation flows naturally. Click in the message field, press the key, speak, and the message appears ready to send.

Documents and notes: Word processors, note-taking apps like Notes or Obsidian, and cloud document editors like Google Docs all expose their text through the accessibility API, so dictation lands exactly where you clicked.

Code and technical writing: Most code editors handle dictation well because they use standard text fields. For adding comments or documentation, click in the comment area and dictate. Dictating code itself is less common but works the same way.

What happens if dictation does not work in an app

If you try to dictate and nothing happens or an error appears, here are the common causes:

1. No field has focus. Click in a text field and try again. The app's UI will tell you if it is waiting for focus.
2. The app does not use standard text fields. Some custom-built editors do not expose their text input through the accessibility API or allow paste. Copy your dictation from your history and paste it manually, or switch to a standard text field for dictation.
3. The accessibility permission is not granted. Check System Settings → Privacy & Security → Accessibility and make sure the app is listed and enabled. If not, click the + button and add it from Applications.
4. The app is not focusable. Some apps do not respond to focus changes from the keyboard or dictation app. This is rare and usually an app-specific issue.

If an app truly does not support dictation, the workaround is straightforward: dictate into a text field elsewhere (your history, a note, or a browser tab), then copy and paste the result into the app.

Privacy and security: Where the text goes

Every dictation you make is stored in your local history, even before it lands in the target app. This means if the paste fails or the app crashes, your words are safe in the history — you can retrieve them and try again.

Nothing about your dictations is sent to external servers. Nothing about which apps you dictate into is tracked or logged. Your data stays on your machine, and the app has no ability to monitor or report what you dictate or where it goes. This is a fundamental difference from cloud-based services.

Dictation across multiple languages

If you dictate in multiple languages, the same focus and field targeting applies. Your dictionary works across languages, and the text lands in the same field whether you are speaking English, Japanese, or any language the model supports.

Limitations and workarounds

The only apps that truly block dictation are those that prevent paste and do not support accessibility input. These are usually:

• Password fields — but most work through accessibility, so they are usually fine.
• Terminal windows — paste is often blocked for security. There is a separate workflow for terminal dictation that uses a different input method.
• Some embedded editors — web apps that build their own text input from scratch might not expose it to the accessibility API.

For all other applications with text fields, dictation works out of the box.