Speech to Text: Live Dictation in the Browser, Set Up Right

By Luuk · Holland

Speech to text in a browser is not a recording feature. The page captures your microphone, hands the audio to the browser, and the browser ships it to its own vendor's recognition service. Chrome sends it to Google, Edge to Microsoft, Safari to Apple. What comes back is a stream of words that the page writes into a text box you can edit.

That single fact explains almost every surprise people hit with dictation: why it needs a connection, why it dies in Firefox, and why a fast connection and a decent microphone matter more than the brand printed on the page. This walkthrough covers the tool on this site, how to set it up for a real session, and where browser dictation stops being the right choice.

What the Web Speech API actually does

The SpeechRecognition interface has existed in browsers since 2013. It is an interface, not an engine. Your code creates a recogniser, sets a language tag, starts it, and receives result events. Where the recognition happens is entirely up to the browser vendor, and in Chromium it happens on a server. MDN is blunt about it: audio is sent to a web service, so recognition does not work offline.

Three properties shape everything the interface can do. lang selects the language model. continuous decides whether the recogniser keeps listening after the first phrase. interimResults decides whether you see a provisional guess before the final text arrives. Everything else in a dictation tool is built on top of those three.

Two implementation details separate a usable tool from a demo. First, event.results is cumulative for the session, so text must be read from event.resultIndex onward rather than from zero, otherwise you re-append the same sentence. Second, Chrome ends a recognition session on its own even when continuous is true, usually after a pause. A dictation page that does not restart the recogniser from its onend handler simply stops listening mid-sentence, which users read as a broken microphone.

First dictation: the order that avoids problems

The sequence matters more than any toggle, because half the failures people report are setup mistakes.

1. Open the page in Chrome, Edge or Safari. Firefox has no recognition engine at all, so it cannot run this; the page tells you so instead of failing silently.
2. Choose the language before you press start. Switch the recogniser's language mid-session and the browser keeps the old model until the next session.
3. Press Start dictation and accept the microphone prompt. The permission is asked once per site, per browser profile.
4. Speak a full sentence, then pause. The final text lands in the transcript box; in-progress words appear in grey above it.
5. Press Stop when you are done, or leave continuous mode running and let it restart between phrases.

If a session returns nothing at all, the usual causes are a muted input device, another application holding the microphone exclusively, or a blocked permission that was dismissed rather than allowed. The page raises a toast for a denied microphone and for a session that heard no speech, so the two cases are distinguishable.

Picking a locale from 101 options

The language picker on this page lists 101 regional locales covering more than sixty languages, ordered alphabetically by the name each language uses for itself. That ordering is deliberate: with a hundred entries and no search field, alphabetical is the only navigation that works, and language variants stay next to their base language, so English (Australia), English (Canada) and English (United Kingdom) sit together.

A locale is not just a language. It sets the acoustic and language model: vocabulary, spelling convention and number formatting all follow the region tag. Some representative pairs show how much the choice changes:

Dictating Spanish with an en-US tag produces confident nonsense, because the engine is matching English phonemes to what it hears. The reverse is just as bad. If you speak two languages in one session, run two sessions and switch the tag between them; the interface recognises one locale at a time.

Not every tag works in every browser. The list is what the recognition interface accepts, and the vendor's service decides the rest: an unsupported locale answers with a language-not-supported error, which this page surfaces as a toast instead of a silent dead button. That is the honest behaviour, because the failure belongs to the browser's service, not to the page.

Continuous mode and interim results

Continuous mode is on by default. Between phrases the recogniser is re-armed automatically, so you can think for a few seconds without losing the session. Turn it off when you want one utterance per press, which is useful for short fields, voice search style input, or when background conversation keeps bleeding into the transcript.

Interim results are also on by default. They show the current guess for the phrase you are still speaking, in grey, and they are replaced when the final version arrives. They are worth keeping for long dictation: seeing the text move confirms that the microphone is live and the service is answering, without waiting for a full sentence to complete. They are worth turning off for noisy rooms, where the provisional text flickers between competing candidates and only distracts.

A note on editing. The transcript is a plain editable text area, not a locked output. Fix a word while dictation continues, and later phrases append after your correction rather than overwriting it. Clear empties the buffer and the interim line in one action, which is faster than selecting all and deleting.

Accuracy, WER, and where it degrades

Accuracy is measured as word error rate: the count of substituted, inserted and deleted words against a reference transcript, divided by the number of reference words. A WER of 5 percent means one wrong word in twenty. Vendors quote figures on clean read speech, which is the easiest possible input, so treat any headline number as a ceiling rather than an expectation.

In practice four things move the error rate:

• Microphone distance. A headset at two centimetres beats a laptop array at sixty, and the gap widens in a room with hard surfaces.
• Vocabulary. Product names, surnames, acronyms and code identifiers are where recognition fails first. Nothing in the interface lets you bias the vocabulary, unlike server APIs that accept phrase hints.
• Speech style. Filled pauses, restarts and self-corrections are transcribed verbatim. The engine is accurate and the output is still unusable, because people do not speak in finished sentences.
• Language tag mismatch, as described above, which produces errors far larger than any acoustic issue.

Punctuation is inferred by the service from prosody, not written by the page. Short pauses often become commas; statement intonation usually ends with a period. Long dictation therefore needs one review pass, and the review is faster than typing the same text from scratch.

Exporting what you dictated

Copy puts the whole transcript on the clipboard as plain text. Download .txt saves it as transcript.txt with no formatting, which opens in any editor and pastes cleanly into a document. If the buffer is empty, the download button reports that there is nothing to save rather than writing a zero-byte file.

Because the transcript is a text area, the workflow that works best is: dictate in chunks, fix obvious recognition errors after each chunk, download once at the end. Long single sessions are riskier, since a browser crash or a closed tab takes the whole buffer with it, and the page keeps nothing.

When not to use browser dictation

Browser dictation is convenient and it is not private in the cryptographic sense. Your audio leaves the device for the vendor's servers. The page itself stores nothing and sends nothing beyond what the interface does, but it cannot make a promise on Google's or Apple's behalf. For patient notes, legal statements or anything under an NDA, use offline software with a local model.

Three other cases have better answers. Transcribing an existing recording needs a file-based service, because this interface only listens to a live microphone. Working with no connection needs on-device keyboard dictation with an installed language pack. Dictating heavy technical content, formulas or code is usually slower than typing, since recognition degrades exactly on the vocabulary you cannot easily spell aloud.

Luuk

Holland · SO reputation 1999 · Badges: 3🥇20🥈27🥉 · SO member since 2011