How to Estimate Reading Time on Any Web Page Automatically

Medium, Substack, and some blog platforms show a reading time estimate
next to article titles. But most news sites, documentation pages, research
papers, and independent blogs don't. You click through to an article and
have no idea whether it's a 2-minute read or a 30-minute commitment.

Having this information upfront changes how you manage your reading. You
can read a 3-minute article now, bookmark a 15-minute one for later, or
decide a 25-minute deep-dive needs to be scheduled rather than skimmed.

How reading time is calculated

The standard method is simple:

reading_time_minutes = word_count / words_per_minute

The average adult reading speed is typically cited as 200-250 words per
minute for normal comprehension. Medium uses 265 wpm. Most reading time
estimators use 200-240 wpm.

For purely text articles, this is reliable within about plus or minus 20%.
Technical content with code samples takes longer (code slows reading
significantly). Visual content with many images takes less time for the
text portion but requires time to examine images. Articles with complex
data tables require extra time.

Reading Progress Bar's reading time feature

Reading Progress Bar calculates reading time for every page and displays
it in two ways:

1. As a time-remaining tooltip on the progress bar (hover to see
approximately 12 minutes remaining)

2. As a badge on the extension icon showing total estimated reading time
for the current article

The calculation uses content-area detection to count only the main article
text, excluding navigation, comments, and footer content. The word count
and reading time are based on the extracted content region.

For technical articles, you can adjust the WPM rate in settings. 160 WPM
is recommended for developer documentation (code blocks and technical
concepts slow reading significantly) and the default 220 WPM for regular
prose.

Reading time on search results pages

A useful extension pattern: some reading-time tools inject estimates into
Google search result listings. Before you click through, you can see that
the first result is an 8-minute article and the second is a 2-minute piece.

Reading Progress Bar supports this for search results — after the search
page loads, the extension fetches the content length for top results
and injects reading time estimates next to each link.

This is an experimental feature (it requires background fetching of each
result URL, which adds a small amount of network activity) and is disabled
by default. Enable it in settings under Search Integration.

Calibrating your reading speed

If you find the default estimates consistently under or over, you can
calibrate against a known-length article:

1. Find an article you've read where you know the word count
(Medium shows this, for example)
2. Time yourself reading it
3. Calculate your actual WPM: words divided by minutes
4. Update the WPM setting in Reading Progress Bar to match

For most people, personalized WPM settings make the estimates significantly
more accurate. A fast reader at 300 WPM will find default estimates feel
too long; a careful reader at 160 WPM will find them too short.

Reading time and decision-making

The most underrated benefit of reading time estimates isn't knowing when
you'll finish — it's making better decisions about what to read at all.
When you can see that a search result will take 3 minutes versus 18 minutes,
you can consciously choose based on your current context.

In a 15-minute window before a meeting, the 3-minute article is the right
choice. The 18-minute piece gets bookmarked for later when you have a
proper reading block. Without estimates, you click the first result,
find it's a massive deep-dive, read two paragraphs, get pulled away, and
come back having neither read it properly nor made a conscious choice.

For newsletters specifically

Email newsletters that link to articles don't always include reading time
estimates on the linked articles. Once you click through, Reading Progress
Bar shows you the estimate. Over time, you'll develop a calibrated sense
of which publications consistently run 5-minute pieces versus 20-minute
features, which helps you schedule your reading time accordingly.

For documentation in particular

API documentation and technical guides benefit from reading time in an
unusual way: they're not meant to be read cover-to-cover, but having a
sense of the document's length helps you decide whether to skim for the
specific section you need or read through for full context.
A 4-minute doc is worth reading fully. A 45-minute spec document should
be searched and navigated, not read linearly. Knowing which situation
you're in before you start saves both time and the frustration of being
half an hour into a document when you only needed one specific answer.

Estimating time for multiple articles before a reading session

Before a focused reading block (say, 30 minutes of catching up on articles
you've bookmarked), open your saved articles in tabs and glance at the
Reading Progress Bar estimate on each one. You can then prioritize:
read the two 10-minute pieces today, save the 25-minute deep-dive for
when you have more time. This micro-planning habit makes your reading
sessions more predictable and reduces the frustration of starting a
long article when you only have a few minutes.