SpeechRecognition browser support

Short answer

SpeechRecognition — the speech-to-text half of the Web Speech API — is available in Chrome, Edge and Safari (desktop and mobile) and in Samsung Internet — as webkitSpeechRecognition everywhere, and also under the standard name SpeechRecognition in current Chrome versions. It is not available in Firefox. Even where the object exists, recognition usually depends on a vendor's online service, so it can fail in browsers or apps that don't have access to that service. (Looking for text-to-speech instead? See speechSynthesis browser support.)

Support table

Because browser behaviour changes with releases, treat this as orientation and confirm against MDN's compatibility table for the versions you target. You can also run the live check on our browser support page to see whether your current browser exposes the API.

Minimal working example

const Recognition = window.SpeechRecognition || window.webkitSpeechRecognition;
if (!Recognition) {
  showFallback(); // e.g. a text box, or record audio and send it to your own service
} else {
  const rec = new Recognition();
  rec.lang = 'en-US';          // BCP 47 tag; always set it explicitly
  rec.interimResults = true;   // partial results while the user speaks
  rec.continuous = false;      // one phrase; see "continuous mode" below
  rec.onresult = (e) => {
    const text = Array.from(e.results).map(r => r[0].transcript).join('');
    output.textContent = text;
  };
  rec.onerror = (e) => console.warn('recognition error:', e.error); // not-allowed, network, no-speech...
  button.onclick = () => rec.start(); // must be triggered by the user
}

Requirements that cause most failures

• HTTPS. Microphone access needs a secure context (https:// or http://localhost).
• Microphone permission. The user must allow it. Inside an iframe, the embedding page needs allow="microphone". On managed work or school devices, an administrator policy (for example Chrome's AudioCaptureAllowed) can block the microphone; check chrome://policy or edge://policy.
• A user gesture. Call start() from a click or tap.
• A network connection for server-based recognition (Chrome, Edge). Offline, expect a network error unless on-device recognition is available.

Continuous mode and long dictation

Setting continuous = true keeps a session open across pauses, but no browser promises unlimited sessions: recognition ends after a stretch of silence, after a period of time, or when the tab loses focus, and on mobile it's more aggressive still. For dictation-style apps, listen for end and call start() again while the user still wants to dictate, and keep the final results you already received. Safari's continuous mode has historically been less reliable than Chrome's, so test it on real Apple devices.

Languages

Set rec.lang to a BCP 47 tag such as en-GB, es-MX, ru-RU, hi-IN, ml-IN (Malayalam), th-TH or pt-BR. Language coverage depends on the vendor's service, not on voices installed on the device. For Chinese, distinguish Mandarin (zh-CN, zh-TW) from Cantonese (zh-HK; some services also accept yue-Hant-HK) and test both, as tag handling differs by browser. If you don't set lang, the page's <html lang> or the browser language is used, which is a common source of "it recognizes the wrong language".

On-device recognition

Recognition has traditionally been server-based in Chromium. The specification has since gained options for on-device processing (a processLocally setting, plus SpeechRecognition.available() and SpeechRecognition.install() to check for and download language packs), and current Chrome versions expose them (we confirmed processLocally, available() and install() in Chrome 154). Support in other browsers is missing or new, and on-device language packs cover a limited set of languages: feature-detect these members before using them and keep the server-based path as a fallback.

Privacy

With server-based recognition, the user's audio is sent to the browser vendor (Google for Chrome, Microsoft for Edge) and processed under that vendor's terms. If you build a product on it, say so in your privacy policy. Safari routes audio through Apple's speech services, which may process on-device or on Apple's servers depending on language and device.

Alternatives when the Web Speech API isn't enough

• Record and upload: capture audio with getUserMedia and MediaRecorder (supported in all current browsers, including Firefox and Safari) and send it to a speech-to-text service you control.
• Run a model in the browser: open-source models such as OpenAI's Whisper can run client-side via WebAssembly/WebGPU ports (for example whisper.cpp builds or Transformers.js). Downloads are large but nothing leaves the device.
• Offline engines: Vosk and similar toolkits run locally in desktop or Electron apps.
• Cloud APIs: Google Cloud Speech-to-Text, Azure AI Speech, Amazon Transcribe and others offer consistent results across browsers, at a per-minute cost.

FAQ

Does speech recognition work on iPhone?

Yes, from iOS 14.5, through webkitSpeechRecognition in Safari and every other iOS browser (they all use WebKit). The page must be served over HTTPS and the user must allow the microphone.

Can I enable the Web Speech API in Firefox?

Speech synthesis (text-to-speech) already works in Firefox. Speech recognition does not, and there's no supported setting that turns it into a working feature for users. Use one of the alternatives above.

Why is my browser telling me "your browser does not support SpeechRecognition"?

The site checked for SpeechRecognition/webkitSpeechRecognition and found neither — you're probably on Firefox or an embedded browser. Try Chrome, Edge or Safari, or use the site's text input if it offers one.

Is speech recognition the same as text-to-speech?

No. Recognition turns speech into text; synthesis (what our converter does) turns text into speech. They share the "Web Speech API" name but have completely different support and privacy stories.