Ask your phone to read a message aloud and it just works — naturally enough that you forget a small miracle happened. Between your text and that voice lies a pipeline that solves genuinely hard problems: how to pronounce words it has never seen, where to pause, which syllable to stress, and how to sound like a person rather than a robot reading a spreadsheet.
This is that pipeline, step by step: cleaning the text, converting letters to sounds, adding the music of speech, and the two very different ways engineers have built the final voice.
Step 1: cleaning the text (normalization)
Raw text is messier than it looks. “Dr. Smith paid $42.50 on 10/17” contains an abbreviation, a currency amount and a date — none of which can be pronounced as written. The first stage, text normalization, expands all of it into speakable words: “Doctor Smith paid forty-two dollars and fifty cents on October seventeenth.”
This is harder than it sounds because context decides everything. “St.” is Saint in “St. Louis” but Street in “Main St.”; “10/17” is a date in October but a fraction in a recipe. Modern systems use machine-learned models for these judgments, and normalization errors — the voice reading “SQL” as “sequel” in the wrong meeting — remain one of the most audible failure modes.
Step 2: from letters to sounds (phonemes)
English spelling is famously untrustworthy — “choir”, “quay” and “Worcester” defeat any simple rule. So the next stage converts words into phonemes, the atomic sounds of speech (about 44 in English). This uses pronunciation dictionaries for known words plus learned models that guess pronunciations for unknown ones, letter by letter.
Homographs — words spelled alike but said differently — are resolved from context: “I read the book” versus “I will read it” need different vowels. Get this wrong and the voice sounds confidently illiterate, which is why this stage gets so much engineering attention.
Step 3: the music of speech (prosody)
A string of correct phonemes still sounds robotic without prosody: the pitch, rhythm, stress and pauses that carry meaning. “Really?” rises; “Really.” falls. We stress the new information in a sentence and pause at commas. Stripped of prosody, speech becomes the flat drone of early GPS navigators.
Prosody prediction is the current frontier. Systems analyze sentence structure to decide emphasis and phrasing, and the best ones now handle contrastive stress (“I didn't say YOU did it”) — the kind of nuance that separates a reader from a speaker.
How does a machine learn this musicality? Modern prosody models are trained on thousands of hours of speech paired with text, learning statistical patterns: questions rise, lists pause between items, emphasized words get longer and louder. The newest systems even model speaking style — the difference between reading news and telling a story — by conditioning on a style embedding. It is pattern-matching at scale, and it works startlingly well.
Two ways to build a voice
The older method, concatenative synthesis, stitches together tiny recorded snippets of a real voice actor — thousands of phoneme fragments selected to match the target sentence. Done well it sounds natural, because the sounds are real; done badly it glitches audibly at the joins, and every new voice needs hours of studio recording.
Modern systems are neural: a model trained on speech learns to generate the waveform directly from the phoneme sequence, predicting pitch and timing as it goes. No stitching, no studio sessions per voice — and the model can clone a new voice from minutes of audio. This is why today's assistants sound dramatically better than the robots of 2010.
The voice already in your browser
You do not need a cloud service to try this. Every major browser ships the Web Speech API: a few lines of JavaScript with speechSynthesis.speak() will read any text aloud using the device's built-in voices, entirely offline. Quality varies by operating system — desktop voices tend to beat mobile ones — but for accessibility features, reading tools and prototypes it is remarkably capable.
The privacy angle is worth noting: because synthesis happens on-device, nothing you have read aloud is sent anywhere. Cloud voices sound better, but they require uploading your text. For sensitive documents, the browser's built-in voice is the right trade.
Frequently asked questions
Why do some voices still sound robotic?
Usually weak prosody, not bad pronunciation. The phonemes are right but the pitch and timing are flat, so every sentence gets the same tune. Older concatenative systems also glitch at snippet joins. Neural voices fixed most of this, which is why the quality gap between 2010 and today is so large.
Can text-to-speech handle languages other than English?
Yes, with per-language models — the pipeline is the same, but normalization rules, phoneme sets and prosody patterns differ by language. Code-switching (mixing languages mid-sentence) is still a weak spot; most systems pick one language's voice and mangle the other.
Is browser text-to-speech private?
Yes. The Web Speech API synthesizes locally using voices installed on your device, so the text never leaves the machine. This makes it suitable for reading confidential documents — unlike cloud TTS services, which by definition receive everything you send them.
What is the hardest part of text-to-speech?
Prosody — deciding how something should sound, not just what sounds to make. Pronunciation is largely solved; making a voice pause, emphasize and emote like a person reading with understanding is where the research frontier sits. Emotional and conversational speech remains the hardest test.
Conclusion
Text-to-speech is three hard problems wearing a trench coat: cleaning messy text, pronouncing it correctly, and performing it like a human. Neural models cracked the performance part in the last decade, turning robotic readers into voices you can listen to for hours. And the simplest version of the whole pipeline is already sitting in your browser, one function call away.