1. Identify which browser voice path you are using
A browser can be only the destination for text, or it can own the microphone session. In the first case, macOS Dictation listens at the system level and attempts to insert text at the focused editable field. In the second, the website exposes a microphone control and Chrome or Safari grants that site access to record audio.
Do not troubleshoot both paths at once. Look for a site-owned microphone button. If none exists and you started the Mac Dictation shortcut, begin with Keyboard, Dictation, and Mac microphone settings. If the site’s own button is active, inspect both the browser permission and the service’s current privacy documentation.
- Mac shortcut and pulsing Dictation cursor: system Dictation path.
- Microphone button inside the webpage: website-owned voice path.
- Extension toolbar icon: extension-owned path with separate permissions.
- Dedicated Mac app shortcut: app-owned path and permissions.
2. Use macOS Dictation in Chrome or Safari
Open System Settings → Keyboard and make sure Dictation is enabled. Note the configured shortcut. In Chrome or Safari, click a supported editable field, start Dictation, speak, then stop and review the inserted text before submitting the form.
Custom editors, code canvases, payment widgets, remote desktops, and cross-origin embedded fields do not all expose a normal Mac insertion point. If the cursor does not accept text, test a plain textarea on another page and then TextEdit. That separates the speech recognizer from the web field.
- Confirm Dictation is enabled and note its current shortcut.
- Click inside the exact editable field before speaking.
- Stop Dictation before pressing Return or clicking Submit.
- Use TextEdit as the control test when the browser field fails.
3. Grant website microphone access only for a site-owned feature
Chrome documents per-site microphone controls under Settings → Privacy and security → Site settings → Microphone. Safari exposes Ask, Deny, and Allow under the active Website Settings or Safari → Settings → Websites → Microphone.
Those controls govern audio captured by the website. They are not the switch for macOS Dictation listening at the system level. Grant a site microphone access only when you intentionally use that site’s recording, call, caption, or native voice-typing feature.
4. Treat Google Docs Voice typing as its own browser service
Google Docs is a useful exception because it has a native Tools → Voice typing command. Google says the browser controls the speech-to-text service and then sends the resulting text to Docs. That path needs browser and docs.google.com microphone permission.
Do not use the Docs workflow as proof that every Chrome text box has a built-in voice-typing menu. For ordinary fields, use macOS Dictation, another system-wide dictation app, or an extension whose permissions and processing you have reviewed.
5. Fix Chrome or Safari voice typing in the right order
First test the microphone and Dictation in TextEdit. If TextEdit also fails, check the selected input device, input level, Dictation language, shortcut, Voice Control state, and System Settings → Privacy & Security → Microphone.
If TextEdit works but a normal browser field does not, confirm the field is editable, refresh the page, disable conflicting writing extensions for one test, and try a plain textarea. If a website microphone button fails, check that specific site’s permission in Chrome or Safari, then the browser’s Mac microphone permission and any work or school management policy.
- TextEdit fails: diagnose the Mac input and Dictation path.
- Only one custom editor fails: diagnose focus and field compatibility.
- A site microphone fails: diagnose browser, site, and macOS permission layers.
- An extension fails: review its own shortcut, permissions, and processing path.
6. Review text before the browser can act on it
Browser fields often have side effects: Return can submit a search, send a message, post a comment, accept a form, or execute a command in a web terminal. Stop listening, inspect the complete text, recipient, destination, and attachment state, then submit manually.
For credentials, secrets, financial instructions, legal text, destructive commands, or exact code syntax, compose in a controlled editor and paste only after review. A speech recognizer cannot know whether a wrong word is merely awkward or operationally dangerous.
7. Keep the processing claim tied to the invoked path
The browser displaying the text does not prove that the browser processed the speech. macOS Dictation follows Apple’s current configuration-specific processing disclosure. A website microphone follows that site and browser. An extension follows its developer’s terms. A dedicated local app follows its own product boundary.
Check the active path before sensitive use. Do not describe every browser voice workflow as cloud-based, and do not describe every Mac shortcut as guaranteed offline.
8. Use IraVoice only for its narrower cross-app job
IraVoice 0.7.1 uses Right Option for held-key Dictate and Globe for Voice-to-Spec on macOS 26+ Apple-silicon Macs. Speech recognition and supported formatting run on the Mac. It does not require a website microphone permission because it is not a website speech service.
IraVoice still needs Mac Microphone and Accessibility authorization, and custom web editors can reject direct insertion. It falls back to reviewable clipboard delivery rather than claiming universal browser compatibility. It does not operate a browser, click Submit, choose a recipient, or replace a site’s native call, caption, recording, or voice-command feature.