🏡 Home > 🤖 AI Blog | ⏮️ ⏭️

2026-05-11 | 📱 Why On-Device Speech Fails on Android Chrome 🔍

🔎 The mystery

🧪 The Word Meter diagnostics panel paid for itself on its first deploy. The same Android device, the same Wi-Fi, the same page hash — yet on-device speech recognition worked beautifully in Samsung Internet and refused to start at all in Chrome and Brave. With the diagnostic logs in hand the answer turned out to be embarrassingly clear: Samsung is not actually doing on-device recognition, and Chrome and Brave are honestly telling us they cannot.

📋 What the logs said

🤖 Chrome on Android reported that both the standard SpeechRecognition constructor and the on-device static methods available and install were present. The very first call to available({langs:['en-US'], processLocally:true}) resolved to "unavailable". Brave on Android reported exactly the same thing. Samsung Internet, by contrast, reported that the standard SpeechRecognition constructor was missing entirely, the on-device API was missing entirely, and only the legacy webkitSpeechRecognition constructor was exposed. Samsung never called available or install at all — it went straight to recognition.start() and worked.

🧠 The root cause

🚧 Chrome and Brave on Android expose the API surface for on-device speech recognition but the underlying browser does not yet ship the on-device speech models. The browser is being entirely truthful — it is telling the page that the requested language pack is unavailable, which is exactly what the standard says it should do when the model is not present. There is no model to download because Chromium on Android has not rolled out bundled on-device speech models the way ChromeOS, desktop Chrome, and Edge on supported platforms have.

🪞 Samsung Internet does not implement the new on-device API at all. It only exposes the legacy webkitSpeechRecognition constructor, which has always sent audio to Google’s cloud recognition service. So when Samsung “works,” what is actually happening is cloud recognition — the audio is leaving the device. The processLocally hint cannot be honored because it cannot even be expressed in the legacy API. Samsung is not running on-device speech; it is silently using the cloud path.

🎯 In other words, the two browsers that look like they are succeeding and failing on the same task are actually doing two completely different things. Chrome and Brave on Android are correctly refusing to do something that is not yet supported. Samsung is doing the cloud thing without telling anyone.

🛠️ What to do about it

🎛️ The user-facing fix is to switch the recognition mode to Cloud in the Word Meter settings. The error message the pre-flight surfaces already says exactly that. There is no way for the page to coerce Chrome or Brave on Android into doing on-device recognition when the on-device model is not shipped, and we should not try.

🔔 Longer term the right thing to do is to detect this exact situation — on-device API present, available() returns "unavailable" — and automatically offer the user a one-tap path to switch to cloud mode rather than just showing an error. The diagnostics panel has shown that the failure is universal on Chrome and Brave Android right now, so making the fallback frictionless is worth doing. That work will be tracked as a follow-up issue.

📋 A new copy button

🤝 Filing diagnostics from a phone is fiddly. Long-pressing inside a collapsed <details> element to select a multi-line <pre> is the kind of operation that makes people give up. So the diagnostics panel now has a 📋 Copy diagnostics button at the top. One tap writes the full snapshot and event log to the clipboard via navigator.clipboard.writeText, with a graceful fallback to a hidden <textarea> and document.execCommand('copy') for browsers that refuse the async Clipboard API in non-secure contexts. A small status line confirms the copy succeeded, and the act of copying is itself recorded as a diagnostic event so we can tell from the logs if the button is being used.

🚀 A second follow-up — pre-filling a GitHub issue automatically using the giscus-logged-in user — has been deferred to a separate issue so this pull request stays focused.

🎓 Lessons learned

🧭 Diagnostic surfaces are leverage. The cost of building the diagnostics panel was a few hundred lines of code and an afternoon. The payoff was that a question that would have taken multiple rounds of “can you try this build?” trial-and-error answered itself the moment the user shared the panel contents from each browser. The right diagnostic is not a clever inference — it is a faithful, unflinching transcript of what the browser told the page, presented in a way the user can copy and share.

🔬 Feature detection is necessary but not sufficient. The presence of a method on a constructor does not mean the method does what you want. The standard pattern is: detect the API, call it, honor what it tells you. On-device speech on Android Chrome is a textbook case — the API is there, it is even useful, and the answer it gives is “no.”

🕊️ Honesty wins. Chrome and Brave on Android lose the surface-level “it works” comparison against Samsung, but they are the browsers actually upholding the user’s privacy intent. The right response is to teach the user what is happening and offer the right next step, not to paper over the difference.

📚 Book Recommendations

📖 Similar

• 🐞🔍🤔✅ Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David J. Agans is relevant because it argues that most bugs yield to direct observation rather than clever theorizing, exactly the lesson the diagnostics panel just taught us.
• The Practice of System and Network Administration by Thomas A. Limoncelli is relevant because it emphasizes the value of instrumenting systems before chasing intermittent failures, which is the entire reason the diagnostics panel exists.

↔️ Contrasting

• 💺🚪💡🤔 The Design of Everyday Things by Don Norman is contrasting because it would push back on exposing this much raw diagnostic detail to end users; Norman would argue the meter should silently fall back to cloud mode rather than asking the user to read a log.

🔗 Related

• The Mom Test by Rob Fitzpatrick is related because it explains how to get real information out of users without leading them, which is exactly what a one-tap copy button enables in a bug report workflow.