Why General Text-to-Speech Extensions Don't Work Well on Twitter (And What Does)

The Problem

Twitter doesn't serve your entire feed as static HTML when you load the page. Instead, it uses JavaScript to load tweets dynamically. As you scroll, more tweets are fetched from the server and inserted into the page.

This is called lazy loading. It's efficient for the browser, but it breaks traditional TTS extensions that expect a static page with all content already loaded.

General TTS extensions can only read what's visible on the page right now. If you start listening from the top of your feed, the extension might read the first 10 tweets, then stop because it's still reading the same first 10 even though new tweets have been loaded below.

The Problem

Twitter uses React, a JavaScript framework that maintains a "virtual" representation of the page separate from the actual DOM. When you scroll, React updates the virtual DOM, which then updates the real DOM.

Extensions that try to query the DOM directly (looking for specific HTML elements) can get confused because the DOM structure is constantly changing, and the structure might not match what they expect.

For example, an extension might look for a div with class tweet-text. But React might change that class name, or restructure the element hierarchy. Now the extension can't find tweets at all.

Twitter updates its structure regularly, which breaks extensions that rely on scraping specific DOM elements.

The Problem

When a general TTS extension like Read Aloud is told to read the page, it reads all visible text. That includes:

• The tweet text (what you want)
• The author name (okay, you might want this)
• The timestamp ("8:42 AM · Mar 14, 2026")
• The view count ("125.3K Views")
• The engagement metrics ("1.2K Likes")
• The action buttons ("Like", "Reply", "Share", "More")
• Promoted tweets and advertisements
• Navigation text ("Explore", "Bookmarks", "Messages")
• Collapsed replies ("Show more replies")

From a text perspective, all of this is "text on the page." But from a user perspective, only the tweet content is valuable. The rest is noise.

A feed-specific tool like Xeder understands which text is a tweet, which is metadata, and which is an advertisement. It can filter accordingly.

The Problem

Chrome has a known bug where its built-in text-to-speech cuts off after approximately 14 seconds when using pre-loaded voice packs.

If you're using Chrome's native TTS (not a cloud service), and a tweet is long, or you're reading multiple tweets in sequence, the audio stops abruptly at 14 seconds.

This affects any extension using Chrome's built-in TTS without cloud services. It doesn't affect cloud-based TTS like Google Cloud, Azure, or Amazon TTS.

Xeder uses Google Cloud TTS, which is not affected by this bug.

The Problem

When you manually copy a tweet and paste it into a TTS tool (like Speechify), you lose context:

• You lose the author (you have to copy that separately)
• You lose the thread structure (which tweet is a reply to which)
• You lose engagement signals (how many people liked it)
• You lose the timestamp and context of when it was posted
• You have to repeat this process for every tweet

You're no longer reading a feed. You're reading isolated text snippets.

A tool like Xeder reads your feed as a feed, preserving all the relational information between tweets.

The Problem

Twitter (now X) is a living product. The team regularly updates the HTML structure, changes class names, reorganizes components, and modifies how the DOM is built.

An extension that works great today might break in a month if Twitter changes its DOM structure in a way the extension wasn't designed for.

This is why Tweet2Audio, an older Twitter TTS extension, doesn't work anymore. It was built when Twitter had a different HTML structure. When Twitter changed, the extension broke. The original author stopped maintaining it, so it stayed broken.

A tool needs to be actively maintained and specifically designed for Twitter to stay working as the platform evolves.