Text to Speech in the Browser: Hear Your Writing Out Loud
How browser text to speech reads any passage aloud with your system voices, why local synthesis matters, and how rate, pitch, and voice controls help.
Text to Speech in the Browser: Hear Your Writing Out Loud
There is a strange gap between reading a sentence and hearing it. On the page, a clumsy line slips past because your eyes already know what it was supposed to say. Played out loud, the same line stumbles, doubles a word, or runs on for forty syllables without a breath. Browser text to speech closes that gap with nothing more than the code already shipping inside Chrome, Edge, Safari, and Firefox.
This post walks through how that works, what the Web Speech API can and cannot do, and a handful of everyday uses where listening beats reading. You can follow along in the text-to-speech tool as you read.
How the browser actually speaks
The browser's speech synthesis reads text aloud using installed system voices, and the rate and pitch are adjustable. That single sentence hides most of what you need to know.
Every modern browser exposes an interface called SpeechSynthesis, reachable in JavaScript as window.speechSynthesis. You hand it a string, it splits that string into spoken sound, and it streams the audio straight to your speakers. Crucially, the voices it uses are not downloaded from a website. They come from your operating system. macOS ships its own Siri-derived set, Windows ships another, and Android and iOS each bundle a different lineup. Whatever your machine has installed is exactly what the browser can offer.
That design has two consequences worth internalizing. First, the voice list is yours alone. A voice you fall in love with on your Mac may simply not exist on a colleague's Windows laptop, where the same text falls back to the default. Second, because the synthesis happens on your own device, your text never travels anywhere. No API key, no upload, no per-character billing. For most standard system voices, you can pull the network cable and the reading continues without missing a word.
The controls that matter: rate, pitch, voice, volume
Four knobs shape how a passage sounds, and each one earns its place.
Voice is the biggest lever. The dropdown groups everything your OS exposes by language and tags each entry with a locale code such as en-US, en-GB, fr-FR, or zh-CN. That tag is not decoration. It tells you precisely which accent and pronunciation rules you are about to hear, which matters enormously the moment you leave English.
Rate runs from a slow 0.5x to a brisk 2x. Slow is for scrutiny and language drills; fast is for getting through a long article while your hands are busy. Most people settle around 1.0x for proofreading and push toward 1.3x for passive listening.
Pitch raises or lowers the voice. It is the control you will touch least, but nudging it can make a flat default voice noticeably easier to listen to over a long session.
Volume is exactly what it sounds like, independent of your system volume so you can keep playback gentle without turning everything else down.
A worked example: proofreading by ear
Here is the routine I lean on most. Suppose I have just written this paragraph:
"Our our onboarding flow guides new users through through setup, and it surfaces the three settings that that matter most before before they ever reach the dashboard."
Reading it silently, my eye glides over the doubled words because it autocorrects to the intended meaning. So I paste the paragraph into the reader, choose a clear en-US voice, leave the rate at 1.0x, and press Play while following along in my editor. The instant the voice says "Our our," the stutter is unmistakable. By the time it reaches "before before they ever reach," I have already flagged four duplicate words that five silent read-throughs had let survive.
When the prose itself is the problem rather than the typos, I drop the rate to 0.9x and listen for the places where I run out of breath. A sentence that forces the voice to barrel through without a pause is a sentence that needs a period somewhere in the middle. Before publishing I usually run the text through a word counter too, because hearing a paragraph drag often means it is simply too long.
Beyond proofreading: accessibility and language practice
Listening is not only an editing trick. It is genuinely useful in three other situations.
Resting your eyes. After hours of screen time, one more report is painful to read. Paste it, pick a comfortable voice at a gentle 0.9x, lean back, and listen with your eyes closed. Because nothing is uploaded, you can do this with an internal document you would never hand to a cloud service.
Multitasking through long content. A two-thousand-word piece is open but lunch needs making. Push the rate to 1.3x and let it read while you chop vegetables, pausing the moment a section needs your full attention.
Practicing a foreign language. Switch the voice dropdown to an es-ES or ja-JP entry, drop the rate to 0.7x, and listen to how a native-locale voice stresses each word. Repeat the line aloud after it, then nudge the speed back up once you can keep pace. The locale tag guarantees you are hearing the accent you intend, not an English voice mangling Spanish.
The honest limits
Two things trip people up, so it is worth stating them plainly.
You cannot download the audio. The Web Speech API streams sound to your speakers and exposes no recording or file-export hook anywhere in the browser. This is the API's design, not a missing button. If you must capture the audio, run your operating system's screen or audio recorder while playback happens.
And long passages can break on Chrome. Chrome's engine has a long-standing quirk where it silently drops utterances longer than a few hundred characters and never fires its "finished" event, so playback dies mid-paragraph. A well-built reader works around this by splitting your text into sentence-sized chunks and queuing them, which is why a good tool plays a full article start to finish where raw speechSynthesis would stall. If you ever do hit a cut-off, a shorter passage or a different voice usually clears it.
Why local synthesis is the right default
It would be easy to bolt this onto a cloud service and ship downloadable MP3s. The trade is that your text would leave your machine on every play. Keeping synthesis local means no upload, no account, no usage cap, and no reason to think twice before pasting a private draft. You give up the export button and gain the ability to read anything aloud, including the documents you would never trust to a third party. For proofreading, accessibility, and quiet language drills, that is the better bargain.
Made by Toolora · Updated 2026-06-13