How do I get the text to highlight along with the audio in my audiobook?

This page may contain affiliate links from which Blur Studio earns commissions.

Read-along highlighting, where the text on screen highlights in time with the narration, is a genuinely nice experience for readers who want to follow along with both the words and the audio at once. It's common in children's books and increasingly expected in some ebook-plus-audiobook bundles, and visible in a growing number of mainstream reading apps as the feature becomes more standard rather than rare. Getting it to actually work requires more than just having both an ebook and an audiobook file; the text and the audio need to be linked word by word, with precise timing for exactly when each word is spoken.

What actually produces this timing data

That word-level timing is produced by a forced-alignment process: taking your known text and your finished recording, and matching them to generate a timestamp for every word. ElevenLabs' Forced Alignment does this at $0.22 an hour of audio, the same rate as its standard transcription, and handles up to 3GB, 10 hours of audio, or 675,000 characters of text in one job, more than enough for a full-length book.

What it doesn't do is build the actual reading experience for you. It returns raw timing data; turning that into an actual synced, highlighting reading interface is a separate development task, building or using an app that takes those timestamps and highlights the matching text as the audio plays, and in most projects this reading-interface work takes meaningfully longer than generating the timing data itself.

Check your platform first, before building anything

Before treating this as something you need to build, check whether your actual publishing or distribution platform already offers synced read-along as a built-in feature. Several audiobook and ebook platforms have added this as a standard offering in recent years, in which case you may not need the underlying timing data at all, your platform handles it when you upload both files. This is worth ten minutes of checking before assuming you need a custom build.

ElevenLabs' own ElevenReader app is one concrete example of this already working end to end: it imports an ebook or PDF, generates narration, and shows word-by-word text highlighting synced to the audio as it plays, all inside one app with no separate alignment step for the reader to think about. If your actual goal is giving readers a synced listening experience rather than building that experience into your own branded app or website, pointing readers at an existing reader app that already does this can solve the problem entirely without any development work on your end.

What the timing data actually looks like

It helps to see a concrete example of what Forced Alignment actually returns, rather than thinking of "timing data" as an abstract concept. For the sentence "The quick brown fox jumped over the lazy dog," the API returns a start and end timestamp for literally every word: when "The" begins and ends, when "quick" begins and ends, and so on through the sentence, down to fractions of a second. Building the actual highlighting experience from this means your reading app or website needs to track playback position against these timestamps in real time and apply a highlight style to whichever word's time range the current playback position falls inside, removing it from the previous word as playback advances. That's a genuinely small, well-defined piece of logic once you have the timing data in hand, the harder part is almost always the reading interface around it (page layout, font handling, how text wraps and paginates), not the highlighting logic itself. The same alignment idea is used to sync subtitles, as lining up subtitles with a script you already have shows.

Who actually benefits from this, beyond a nice feature

Synced read-along text isn't purely a polish feature; it has a real, documented role in literacy support, language learning and accessibility. Readers learning a new language often use audio plus synced text specifically to connect how a word sounds to how it's spelled, something static audio alone or static text alone doesn't give them as effectively. Some readers with dyslexia or other reading differences find that following along with synced highlighting reduces the effort of tracking their place on the page, which can be the difference between finishing a book and giving up partway through. If any of these describe a meaningful part of your actual audience, this stops being a nice-to-have polish item and becomes something closer to a genuine accessibility feature worth prioritizing, even for a smaller catalog.

The cost at book scale

Running the numbers for an actual full-length book makes the cost picture concrete. A typical novel runs 10 to 12 hours as an audiobook. At $0.22 an hour for Forced Alignment, that's roughly $2.20 to $2.64 to generate the full timing data for the entire book, a genuinely trivial cost next to any other part of producing an audiobook (narration, editing, cover art, distribution). The real cost of this feature is almost entirely the development time to build the reading interface around the timing data, not the alignment itself, which is worth knowing before assuming this is an expensive feature to add. Producing the audiobook itself is covered in turning your own book into an audiobook.

What I'd actually tell an independent author

For most independent authors, this is a genuine nice-to-have, not a must-have, and treating it as more than that risks spending real development budget on a feature that doesn't move the needle on sales or satisfaction for your specific readers. Readers buy audiobooks and ebooks separately all the time without any expectation of synced highlighting, and the absence of it rarely costs a sale. I'd only prioritize building this if your specific audience (children's books are the clearest case) genuinely expects it, or if a platform you're already publishing through offers it essentially for free once you've uploaded both files anyway. Narration quality across a whole book is reviewed in ElevenLabs for audiobooks.

Other ways to get this timing data

ElevenLabs' Forced Alignment isn't the only route to word-level timing, and it's worth knowing the landscape before committing to one tool. Some TTS platforms, when they generate the narration themselves rather than aligning to audio you already have, can return timing data as a byproduct of generation, since the system already knows exactly when it produced each word. If you're generating narration from scratch rather than aligning to an existing human recording, check whether your TTS provider already gives you this for free as part of generation, which would skip the separate alignment step entirely. Open-source speech recognition models can also be adapted to do forced alignment, though that route needs real technical setup and ongoing maintenance that a managed API avoids. For most independent authors without a developer on hand, a managed API or an existing reader app that already does this is the more realistic path than running open-source tooling yourself.

When this is worth the development work

• You're building or already have a dedicated reading app or platform where a synced experience is the actual product.
• Your audience specifically expects it (children's books, language-learning content).
• Your existing publishing platform doesn't support it and you have the audience size to justify custom development.
• Accessibility is a genuine priority for your audience or your publishing goals, not just a feature to point to.

Outside of those cases, publishing your ebook and audiobook as separate, well-produced files is normally the better use of time and budget. There's no reputational cost to skipping this feature for most independent authors; readers judge an audiobook and an ebook mainly on narration quality and the writing itself, not on whether the two are synced together. Selling the audio version of a guide is covered in selling your guide as an audiobook.

How I'd approach this

If you do have an audience that specifically wants this, or you're building your own reading app or platform as a product in its own right, I can build the full pipeline: generating the timing data, then the actual synced reading interface on top of it. That's genuinely custom development work, not a checkbox feature, so it's worth confirming the demand is real before committing budget to it rather than building it speculatively. One way to test demand cheaply before committing to a full custom build: offer synced read-along for a single chapter or a short piece first, using whichever existing reader app or tool gets you there fastest, and see whether readers actually use and value it before investing in your own branded version of the feature. If you confirm real demand that way, building your own version becomes a much lower-risk decision, since you're building something you already know people want rather than guessing.