If you have ever watched a text to speech app highlight the wrong word, and then watch it slowly fall further and further behind the voice, you have run into one of the most common small annoyances in this category. It is not a bug in the usual sense. It is a shortcut, and most apps take it because measuring properly is harder than guessing.
The guess: timing estimated from letters
The simplest way to build word highlighting is to never look at the audio at all. Instead, the app estimates how long each word probably takes to say, based on things like its letter count, average speaking speed, and maybe a rough adjustment for punctuation. Then it lights up words on a timer built from those estimates.
This works reasonably well for a sentence or two. The problem is that real speech does not move at a constant pace. A narrator pauses at a comma, speeds up through a list, slows down on an unfamiliar name, and takes a breath before a new paragraph. None of that is visible from letter counts alone. Every one of those moments nudges the estimate slightly off, and because the errors are all in the same direction over a long document, they add up. Ten minutes into a chapter, the highlight can be a full sentence ahead of or behind the voice.
Numbers and names make it worse. "2026" takes longer to say as a word than its four characters would suggest. So does an unfamiliar surname, an acronym read letter by letter, or a foreign word the voice slows down for. A letter-count estimate has no way to know any of this in advance, so it just keeps guessing at the same rate and drifting.
The measurement: aligning against the real audio
There is a more reliable way to do this, but it takes more work: generate the audio first, then measure where each word actually falls inside it. This is sometimes called forced alignment. Instead of predicting how long a word will take, the system listens to the finished audio and the original text together, and works out, from the sound itself, exactly when each word starts and stops.
Practically, this means running the generated audio back through a speech recognition system and matching its output against the original text, word by word. The result is not a guess about typical speaking pace. It is a measured timestamp, taken from the actual recording you are about to hear.
ReadLoud does this for every document. After the audio is generated, it is aligned against the text using Google's speech-to-text as the reference, which is the same category of technology used for automatic captions. Because the alignment is measured rather than estimated, the highlighted word should track the voice closely, sentence tint and all, even through the exact moments that break letter-count guessing: names, numbers, pauses, and changes in pace.
Why this matters more than it sounds like it should
For most casual listening, a highlight that is a little off does not ruin much. You still follow the story. But for a few common uses, accurate highlighting is not a nice-to-have:
- Following along while reading, not just listening. If you are using audio to help you get through a dense document while your eyes track the page, a highlight that drifts becomes actively distracting rather than helpful. You end up either ignoring it or losing your place.
- Dyslexia and attention differences. Word-level highlighting is often recommended specifically because it gives a second, visual anchor to match against the sound. That anchor is only useful if it is actually where the voice is.
- Studying and research reading. If you want to click back to "where was that number mentioned" or jump to a specific claim, the click only lands in the right place if the underlying timing is accurate, not estimated.
- Any switch in speed. A drift that is small at 1x tends to get worse, not better, when you speed up, because the fixed-rate guess and the real audio pace apart even faster.
What this looks like in practice
On ReadLoud, because every word has a measured position, a few things follow naturally from that:
- Sentence tint alongside word highlighting, so you can see where you are at a glance even without focusing on a single word.
- Click any word to start reading from there. Since the click target and the audio position are the same measured timestamp, this actually lands where you clicked.
- A sync slider and auto-scroll that stay meaningfully attached to the audio instead of a separate, disconnected timer.
- Switching voice mid-document without losing your place, because the new section is aligned the same way as the rest.
None of this is exotic. It is the difference between building a feature around an estimate and building it around a measurement of the thing you are actually going to hear.
The honest limits
Alignment quality depends on the underlying speech recognition, and no system is flawless on every word, especially with heavy background pauses, mixed languages in one sentence, or very unusual names. It also only covers text that made it into the generated audio in the first place. If a PDF has headers, footers, or citation brackets stripped out during extraction, ReadLoud shows that skipped text dimmed on the page, so you can see what was left out rather than being surprised by a silent gap.
Seeing it for yourself
The easiest way to notice the difference is to listen to something with a name, a number, and a pause in it, and watch whether the highlight keeps pace or starts to lag. You can read more about how the whole reading experience fits together on how it works, including fonts, themes, and the rest of the reading view.
