Web Speech API: Speech Recognition in the Browser

The Web Speech API's SpeechRecognition interface lets a web page turn speech into text with a few lines of JavaScript. Chrome and Edge have the broadest support, Safari supports it when Siri is turned on, and Firefox has not shipped it in a numbered release. By default, Chrome sends the audio to a server for recognition, so the feature does not work offline ¹. Newer Chrome releases can run recognition on the device ², and a page can require that mode, which is the setting to check when privacy matters.

This guide explains the API from both sides: what happens to a user's voice, and what a developer can count on. If you need dictation in other apps rather than in a page you build, the overview of voice typing in apps covers the options, and speech to text in Chrome compares the routes a user can take without any code.

The Web Speech API lets a page turn speech into text in a few lines

The API has one main object, the SpeechRecognition interface, which a page creates, configures and starts. It reports text through a result event and problems through an error event. The W3C document that defines the API is a Community Group draft dated 15 October 2026 ³. That makes it a working draft rather than a finished standard, and browsers adopt its features at different speeds.

const Recognition = window.SpeechRecognition || window.webkitSpeechRecognition;
if (!Recognition) {
  console.log('Speech recognition is not supported in this browser.');
} else {
  const recognition = new Recognition();
  recognition.lang = 'en-US';
  recognition.interimResults = true;
  recognition.onresult = (event) => {
    const text = Array.from(event.results).map((r) => r [0].transcript).join('');
    console.log(text);
  };
  recognition.onerror = (event) => console.log('Error:', event.error);
  startButton.addEventListener('click', () => recognition.start());
}

Three details in that code matter. The first is the name. The unprefixed name is listed from Chrome 139, and the webkit prefixed name from Chrome 33 ⁴, so the code tries both. The second is the start. A session begins only with the user's agreement, because the specification says browsers "must only start speech input sessions with explicit, informed user consent" ⁵. Start recognition from a button and expect a microphone prompt, which is covered in site microphone permission. The third is the result shape. By default a recognition returns a single result, because the continuous setting defaults to false ⁶. Set continuous to true for long dictation, and read every result from event.resultIndex onward, as the question on adding speech recognition with JavaScript shows in full.

Feature detection is the first thing to write

Check for the constructor before you build any interface. A page that calls new SpeechRecognition() in a browser without it will throw an error at runtime, so a missing constructor should lead to a plain text box, not a broken button. The check in the code above covers both names, and a page should also handle the error that arrives after start, such as a missing network connection ⁷ or a blocked session ⁸.

Browser support is uneven, and Chrome and Edge have the broadest

The table below uses MDN's compatibility record, which lists the first version of each browser that supports the interface. The record is the most precise public source we found, and its entries change as browsers ship, so check it before you release a page.

In MDN's data, Edge is recorded as a mirror of Chrome because it uses the same engine, so the Edge row follows Chrome's record ⁹. The value preview is a placeholder for a version that is not yet known. MDN uses it "when the future stable version number is unknown or uncertain" ¹⁴. For Firefox, that means a stable release is not listed, so do not assume the feature works for your visitors.

Safari works, with Siri as a condition

WebKit's announcement of Safari 14.1 ¹⁰ says that "Safari supports speech recognition powered by the same speech engine as Siri" ¹¹, and that the transcription covers "over 50 languages and dialects" ¹⁵. The condition is that users must have Siri turned on, in System Preferences on a Mac or in Settings on an iPhone or iPad ¹⁶. A page cannot turn it on for the visitor, so a Safari visitor with Siri off cannot use the feature, and the page should handle that case.

WebKit's announcement does not say whether Safari's recognition runs on the device or on Apple's servers. Do not assume either. Check Apple's current documentation for the version your users run.

Firefox is the browser to test, not the one to assume

A January 2022 revision of Mozilla's wiki said that Chrome, Edge, Safari and Opera supported the speech-to-text form of the API, but Firefox did not ¹³. The current compatibility record still lists Firefox only as preview ¹². Treat Firefox as unsupported for any feature you cannot afford to lose, and provide a typed fallback.

By default, recognition often runs on a cloud service

In Chrome, speech recognition on a web page uses a server-based engine. MDN says that "on some browsers, like Chrome," the audio "is sent to a web service for recognition processing, so it won't work offline" ¹. The general statement is broader: by default, speech recognition on a web page sends the user's audio to a server-based service ¹⁷.

That default has three effects a developer should plan for.

1. The page depends on the network. When the connection is missing, the page receives a network error rather than text ⁷. Offline dictation therefore needs a different engine.
2. The provider is the browser's choice. The page does not pick the company or the server. For Chrome, the best public account we found names Google. Mozilla's wiki, written by a competing browser maker, says it opts out of letting Google store its voice requests, and that, unlike speech from Chrome, Mozilla's recordings "are not saved and can not be attached to their profile" ¹⁸. We did not find Google's own documentation for this service, so treat the naming as one vendor's account. The question on whether the Web Speech API sends audio to Google sets out the answer and its limits.
3. The audio leaves the device. A user who speaks into a site is, by default, sending a voice recording to a service outside the device ¹⁷. The site's own privacy policy does not change where the browser sends that audio.

On-device recognition is arriving through new options in the specification

The specification adds a processLocally setting. When a page sets it to true, the requirement is strict: recognition "MUST be performed locally on the user's device" ¹⁹. When it is false, the default, the browser may choose either way: "the user agent can choose between local and remote processing" ²⁰. A page that needs privacy should therefore set the value to true and handle the case where the browser cannot comply.

Chrome has shipped the on-device part. Its release notes for Chrome 139 say the Web Speech API gained on-device speech recognition, so a website can make sure that neither audio nor transcribed speech is sent to a third-party service ². MDN still marks the processLocally property as experimental and tells developers to check the compatibility table before relying on it in production ²¹.

The on-device mode needs a language pack. A January 2025 reply in the Chromium discussion estimated each pack in Chrome on Windows, Mac and Linux at about 60 MB ²². The specification handles this with a status check and an install step. A page can ask for the status of a language, and install it when the status is downloadable ²³.

const options = { langs: ['en-US'], processLocally: true, quality: 'dictation' };
const status = await SpeechRecognition.available(options);
if (status === 'downloadable') {
  await SpeechRecognition.install(options);
}
const recognition = new SpeechRecognition();
recognition.processLocally = true;

The code uses the static methods on the interface, which return a status and install a language pack. Before you ship it, check what the browser returns for unavailable, and decide what the user sees. A Windows speech API reported in June 2026 also processes speech on the device without an internet connection ²⁴, but that is an operating-system interface, separate from the browser API a web page calls.

The on-device mode is a request, not a guarantee of every browser

The processLocally attribute is a requirement the browser must honor when it is true ¹⁹. Our sources show a Chrome release note for the on-device mode and no matching note for other browsers, so the same page may get on-device recognition in one browser and a server path in another, or no recognition at all. Test each browser you support and record which path it took.

The API is free for developers, with limits they do not control

We found no price for the API in the specification or in MDN's documentation. What the developer cannot control is the service behind it. The specification lets the browser choose between local and remote processing when the setting is false ²⁰, so the page cannot choose the provider in that case.

Language coverage is the limit you can check. WebKit describes Safari's coverage as over 50 languages and dialects ¹⁵. We did not find a published language count for Chrome, so test each language your users need in each browser instead of assuming it. We also did not find a documented time limit or quota for a single session in the specification or in MDN. Test long dictation sessions in every browser before you rely on them.

Running a model such as Whisper in the page is the alternative

If you need the same engine in every browser, and you can accept a large download, you can run an open speech model inside the page. OpenAI's Whisper models come in several sizes. The smallest, tiny, has 39 million parameters ²⁵, and the largest, large, has 1,550 million ²⁶. Base has 74 million ²⁷, small has 244 million ²⁸, and medium has 769 million ²⁹. The chart shows the multilingual sizes side by side.

The large model is about 40 times the size of the tiny model ³⁰, and OpenAI lists about 10 GB of video memory for it ³¹. Those figures are OpenAI's estimates for running each model, so they guide the choice of size but do not measure a particular laptop.

Transformers.js, a JavaScript library from Hugging Face, runs models in the browser. Its README says that by default the model runs on the CPU through WebAssembly, and that a page can run it on the GPU through WebGPU by setting the device option ³². The pipeline API handles the speech task:

import { pipeline } from '@huggingface/transformers';
const transcriber = await pipeline('automatic-speech-recognition', 'MODEL_ID', { device: 'webgpu' });
const result = await transcriber(audioData);
console.log(result.text);

Replace MODEL_ID with a Whisper model in ONNX format from the Hugging Face hub. Because WebGPU depends on the browser and its graphics driver, a page should check for it and fall back to the CPU path. The question on whether Whisper can run in the browser covers the trade-off in more detail, and running Whisper locally covers the desktop route.

Privacy depends on the browser, not the website

A site can ask for on-device recognition, but the browser decides what it delivers, and the visitor decides what it is allowed to do. In 2025 the W3C Technical Architecture Group was asked to review the on-device proposal, and the request names the main risk. "The primary risk of this new functionality is the potential for fingerprinting" ³³. The review request was opened on 9 January 2025 ³⁴, so it is recent, and the proposal may change before every browser ships it.

Three practical rules follow from the evidence above.

1. Set the on-device request for sensitive audio. Use processLocally for medical, legal or personal dictation, and treat an unavailable status as a reason to warn the user rather than to fall back silently.
2. Say where the audio goes. Tell visitors whether recognition runs on the device or on a server, based on the path the browser actually took, not on what you hoped it would take.
3. Test Safari with Siri off. The feature stops for those users, and the page should show a clear message instead of an empty result ¹⁶.

For free dictation in a browser with no code, see online dictation. If you want dictation in every app rather than one web page, Yap, which we make, runs on Mac and Windows; see the download page for the current versions.

Test the offline, denied and long-session cases before you ship

A demo on your own laptop shows only the happy path. Four cases break most pages, and each should be tested in every browser you support.

1. Go offline. Turn off the network and start a session. On a server-based path, the page should show a message about the connection, because the error arrives as a network code ⁷.
2. Deny the microphone. Block the microphone for the site and start a session. The browser reports that it blocked speech input ⁸, and the page should fall back to a text box.
3. Run a long session. Set continuous to true and speak for several minutes. Check that results arrive in order and that the page does not repeat text. Without that setting, you get one result per recognition ⁶.
4. Check each language. Speak every language you promise, and check the status the browser reports for each one, since language support differs by browser and engine.

Related guides and terms

The browser routes that a user can take without code are covered in speech to text in Chrome, Google Docs voice typing and dictation on Chromebooks. For the engine behind a browser's recognition, see on-device speech recognition, and for the measure used to compare engines, see word error rate. The term Web Speech API covers the names this guide uses.