Why is my text to speech highlighting always a little behind or ahead?

In most apps, the highlight is driven by an estimate of how long each word takes to say, based on letter count and average speaking pace, not by measuring the actual audio. Estimates drift more the longer you listen, and names, numbers, and pauses make the drift worse.

Does changing the speed make the sync worse?

Often, yes. If the underlying timing is a fixed estimate rather than measured from the real audio, speeding up tends to expose the gap between the estimate and the actual pace faster, so a small mismatch at 1x can become a noticeable one at 2x or higher.

Is PDF highlighting worse than plain text highlighting?

Generally yes, and this is a commonly reported issue. PDFs do not have a clean, linear reading order the way plain text does. Columns, footnotes, headers, and page breaks can confuse the mapping between the audio and the text position, which is separate from, and often worse than, ordinary timing drift.

Can buffering or a slow connection cause highlighting to lag?

Yes, in apps that stream audio and text separately, a slow or interrupted connection can cause the two to fall out of step temporarily, especially right after a pause, a skip, or a change in speed, even if the underlying timing data is otherwise fine.

What actually fixes this instead of just reducing it?

Measuring the timing from the real generated audio, rather than estimating it, removes the main source of drift, since the highlight is based on where each word actually falls in the recording instead of a guess about how long it should take. That does not fix separate issues like PDF layout or a bad connection, but it removes the most common cause.

Word Highlighting Out of Sync: Why It Happens and Fixes

If you searched this exact phrase, you have almost certainly watched a highlighted word crawl further and further behind the voice reading it, until you gave up trying to follow along and just listened instead. This happens across a lot of different reading and text-to-speech apps, not just one, and it is worth understanding why before trying to fix it, because the fix depends on which of a few different causes is actually behind it.

Cause one: estimated timing instead of measured timing

The most common reason highlighting drifts is that most apps never actually check the audio to see where each word falls. Instead, they estimate: how many letters a word has, an average speaking rate, maybe a small adjustment for punctuation, and then light up words on a timer built from that guess.

This works fine for a sentence or two. Real speech does not move at a constant rate, though. A voice pauses at a comma, speeds through a list, slows on an unfamiliar name, and takes a breath before a new paragraph, and none of that is visible from letter counts alone. Every one of those moments nudges a letter-count estimate slightly off, and because those small errors tend to accumulate in the same direction over a long passage, they add up. Ten minutes into something, the highlight can be a full sentence off from the actual voice.

Numbers and names make this worse specifically. "2026" takes longer to say than its four characters suggest. An unusual surname, an acronym read letter by letter, or a word in a different language the voice slows for, all throw off an estimate that has no way to know any of that in advance.

Cause two: PDF layout confusing the reading order

PDFs are a second, separate source of the same complaint, and it is worth telling apart from plain timing drift because it is not really a timing problem at all. A PDF does not have one clean, linear stream of text the way a plain text file or a well-structured web page does. Multi-column layouts, footnotes, running headers and footers, and page breaks can all confuse the mapping between "where the audio currently is" and "which word on the page that corresponds to," so the highlight can jump to the wrong column, repeat a header, or skip a section entirely, independent of whether the underlying speech timing itself is accurate.

Cause three: buffering and connection hiccups

In apps that stream audio separately from tracking text position, a slow or interrupted connection can cause the two to fall out of step temporarily, particularly right after you pause, skip, or change speed. This tends to show up as a brief, correctable glitch rather than a steady drift, and it can happen even in an app whose underlying timing data is otherwise accurate, since the problem is delivery, not measurement.

What's worth trying if you're stuck with an app that has this problem

A few things can reduce the annoyance even if they cannot fully fix the underlying cause:

Pause and resume. In apps affected by connection hiccups specifically, a pause and restart sometimes resyncs the two streams, though it will not help with a genuine estimation-based drift, which returns as soon as you keep listening.
Slow down. If the drift is caused by estimated timing, a slower speed gives the estimate more slack before the error becomes noticeable, buying you more minutes before it visibly falls behind, without solving the underlying cause.
Restart at a sentence break. Since drift accumulates over time, restarting playback from the start of the current sentence rather than continuing from mid-drift resets the error to near zero, at the cost of doing that repeatedly through a long document.
Switch to listening only, without following the highlight. Sometimes the simplest fix is to stop trying to visually track a highlight that is not reliable and just listen, treating the text as a reference to glance at afterward rather than something to follow in real time.

None of these actually correct the cause. They manage around it.

What actually fixes it: measuring instead of guessing

The underlying fix is to stop estimating and start measuring. Generate the audio first, then check, from the actual recording, exactly when each word starts and ends, a technique sometimes called forced alignment. Practically, this means running the finished audio back through a speech recognition system and matching its output against the original text, word by word, so the highlight timing comes from what was actually said, not from a guess about how long it should take to say it.

ReadLoud does this for every document, aligning the generated audio against the text using Google's speech-to-text as the reference. Because the highlight position is a measurement rather than an estimate, it should track through the exact moments that break letter-count guessing, names, numbers, pauses, and changes of pace, and it should hold up at higher speeds too, since the measurement scales with the actual audio rather than a fixed guess about pace. On the PDF side specifically, ReadLoud extracts text the way a reader view does, stripping headers, footers, page numbers, and citation brackets that would otherwise confuse reading order, and shows anything it could not cleanly extract dimmed in the text rather than silently misplacing it.

There is also a sync slider if your own sense of timing runs slightly ahead of or behind the measured alignment, since perception of audio-visual sync varies a little person to person even when the underlying measurement is accurate. You can read more about how this works, including the rest of the reading experience, on the how it works page, or the fuller technical explanation in how word highlighting actually works.

A quick way to check which cause you're dealing with

If you want to narrow down what is actually happening before trying fixes, a couple of quick checks help. Listen to a plain text passage with a name or number in it, on the same app, and watch whether the drift appears there too. If it does, the cause is most likely estimated timing rather than anything specific to PDFs. If a plain text passage stays in sync but a PDF of the same content does not, the layout of that particular PDF is the more likely culprit, and the fix is closer to re-extracting or re-formatting the source than adjusting playback settings.

It is also worth testing at your normal listening speed and at 1x separately. If the drift is barely noticeable at 1x but becomes obvious once you speed up, that points toward accumulated estimation error rather than a one-off glitch, since a genuine connection hiccup would show up regardless of speed.

Why this is worth fixing rather than tolerating

A highlight that drifts is not just a minor visual annoyance for everyone. For readers who rely on the highlight as a second anchor alongside the audio, dyslexic readers and anyone with attention differences among them, a highlight that stops matching the voice removes exactly the feature that was supposed to help, and can end up more distracting than no highlighting at all. For studying or research reading, where clicking back to a specific claim or number depends on the click landing where you expect, inaccurate timing breaks that workflow entirely rather than just looking slightly off. It is a small-seeming bug with a bigger effect on the people who depend on the feature most.