Why Chrome stops reading out loud after 15 seconds

You paste a long article into a text-to-speech tool, press play, and the voice starts reading. About fifteen seconds in, it stops. No error, no warning, no end-of-speech event that makes sense. The text is still on screen, the play button still looks armed, but nothing is speaking. If this has happened to you on desktop Chrome, you are not doing anything wrong. You are hitting one of the oldest open bugs in the browser.

The behavior is specific and repeatable. On desktop Chrome, a single long SpeechSynthesisUtterance stops producing audio after roughly fifteen seconds. Short text finishes fine, which is why so many demos look like they work. It is only when you feed it a full paragraph or a whole article that the cutoff shows up. The Chromium issue tracking this has been open for years, filed not long after the Web Speech API first shipped, and it has survived many Chrome releases without a real fix.

The cause is a timeout deep in how Chrome talks to the operating system's speech engine. Chrome does not synthesize audio itself. It hands your utterance to the platform text-to-speech service and waits for progress callbacks. When those callbacks do not arrive frequently enough, an internal watchdog decides the utterance has stalled and quietly tears it down. Long text with sparse progress events trips that watchdog even though nothing has actually gone wrong. The speech was mid-sentence and healthy; the browser just gave up on it. The giveaway is that the utterance often fires no proper end event either, so your own code cannot even tell the reading was interrupted rather than finished, which is why a homemade player tends to just sit there looking done.

The first common workaround treats the symptom directly. You set up a repeating timer that calls 'speechSynthesis.pause()' immediately followed by 'speechSynthesis.resume()' every ten to fourteen seconds while speech is playing. The pause-then-resume pair nudges the synthesis pipeline and resets the internal timeout before it can fire, so the utterance keeps going. It is a hack, and it looks like one in the code, but it is the most widely used fix because it keeps a single utterance alive without restructuring anything. You clear the timer when speech ends or when the user stops, or you end up with a phantom timer poking a dead synthesizer.

The second workaround avoids the problem instead of fighting it. You split the text into short chunks at sentence boundaries and queue each chunk as its own utterance with 'speechSynthesis.speak()'. Because no single utterance ever runs long enough to reach the fifteen-second wall, the watchdog never trips. The browser reads one sentence, fires its end event, and moves to the next queued utterance automatically. This tends to be the more robust approach: it also gives you natural points to track progress, highlight the current sentence, or let the user skip forward. The tradeoff is that chunking badly, mid-clause or on an abbreviation, can add small unnatural pauses, so the sentence splitting has to be reasonably careful.

Which voice you picked matters too. The remote "Google" voices, the ones where 'localService' reads false, stream audio from Google's servers and behave differently under the cutoff than the offline voices that run on your device, which do their work locally through the operating system. Some voice and platform combinations reach the wall faster or slower, and a few barely reproduce it at all. This is part of why the bug is so confusing to diagnose: change one voice in the dropdown and the timing shifts, which makes it feel intermittent when it is actually structural.

It is also mostly a desktop Chrome problem, not a universal one. Edge, Firefox, and the mobile browsers do not reliably reproduce the fifteen-second cutoff the same way. So a homemade script can pass every test on a phone and on Firefox, then fail the moment a real user opens it in Chrome on a laptop, which is exactly the environment most people are in. That mismatch between where you test and where people use it is what makes this bug a rite of passage for anyone who writes their own text-to-speech feature.

This is the deeper reason a naive do-it-yourself approach falls over. Calling 'speechSynthesis.speak()' on your text is genuinely one line, and the demo works, so it looks finished. But shipping it means also handling the keep-alive timer or the sentence queue, cleaning up when the user stops, coping with voices that load asynchronously, and testing across browsers that each break in their own way. A reading tool that has already solved this, Wordcast among them, absorbs all of that so a long article just plays to the end. The Web Speech API is free and built into your browser, but "free" and "handles the edge cases" are not the same thing, and the fifteen-second cutoff is where that gap becomes obvious.