Santaji GadeJavaScript, Development2 days ago6 Views

A reading time calculator for blog posts uses one formula: word count divided by reading speed — 200-265 WPM depending on your source.
Table of Contents
ToggleA reading time calculator for blog posts uses one simple formula: word count divided by reading speed in words per minute. Medium uses 265 WPM, Google's own reference standard is 200 WPM, and most implementations land somewhere in the 200-250 range for general web content.
Displaying reading time isn't just a nice-to-have. Research shows it can increase engagement by 30%, since readers can decide whether they have time to commit before they start.
Here's the exact formula, real working JavaScript, and the adjustments that make an estimate meaningfully more accurate than a bare word-count division.
The base formula behind every reading time calculator is straightforward: Reading Time = Word Count ÷ Words Per Minute. A 1,000-word article at 200 WPM comes out to 5 minutes.
The WPM value you pick matters more than it seems. Medium uses 265 WPM, general web standards range from 200-250, and Google's own reference point is 200 WPM. Technical or dense content should use a slower estimate, since research shows comprehension drops significantly above 300 WPM.
Here's the simplest working version: grab the article text, split it into words, divide by WPM, and round up so a reader is never disappointed by an underestimate.
function calculateReadingTime(text, wpm = 238) {
const words = text.trim().split(/\s+/).length;
const minutes = Math.ceil(words / wpm);
return minutes;
}
// Usage
const articleText = document.querySelector('.article-content').innerText;
const readTime = calculateReadingTime(articleText);
document.getElementById('reading-time').innerText = `${readTime} min read`;
Word count alone understates total engagement time for heavily illustrated content. Each image adds roughly 12-20 seconds of viewing time, decreasing slightly for each additional image as readers skim faster through a gallery. Complex tables or figures can add 30-60+ seconds for real comprehension.
function calculateReadingTimeWithImages(text, imageCount, wpm = 265) {
const words = text.trim().split(/\s+/).length;
const wordMinutes = words / wpm;
// First image adds 12s, decreasing by 1s per image down to a 3s floor
let imageSeconds = 0;
for (let i = 0; i < imageCount; i++) {
imageSeconds += Math.max(12 - i, 3);
}
const totalMinutes = wordMinutes + (imageSeconds / 60);
return Math.ceil(totalMinutes);
}
// Example: 1,500 words, 5 images, 265 WPM ≈ 6-7 min read
const readTime = calculateReadingTimeWithImages(articleText, 5);
Rather than hardcoding values, scan the actual rendered article container so the estimate updates automatically whenever content changes, no manual recalculation required.
function autoReadingTime(containerSelector, wpm = 238) {
const container = document.querySelector(containerSelector);
if (!container) return null;
const text = container.innerText || container.textContent;
const words = text.trim().split(/\s+/).filter(Boolean).length;
const images = container.querySelectorAll('img').length;
const wordMinutes = words / wpm;
let imageSeconds = 0;
for (let i = 0; i < images; i++) {
imageSeconds += Math.max(12 - i, 3);
}
const totalMinutes = Math.ceil(wordMinutes + imageSeconds / 60);
return {
minutes: totalMinutes,
words: words,
images: images,
label: totalMinutes < 1 ? 'Less than a minute' : `${totalMinutes} min read`
};
}
const result = autoReadingTime('.article-content');
document.getElementById('reading-time').innerText = result.label;
Different content types genuinely need different WPM assumptions for an accurate estimate.
| Content Type | Recommended WPM | Why |
|---|---|---|
| Technical documentation | 150 WPM | Readers re-read sections, code needs careful parsing |
| Standard blog posts | 200-238 WPM | General web reading speed, Google's own reference point |
| Casual/listicle content | 250-300 WPM | Readers skim familiar, easy-to-scan content |
| Fiction/narrative | 260 WPM | Faster natural flow than non-fiction analysis |
Enter a word count and pick a reading speed to see the estimate update live.
Enter your word count and select a reading speed
A short list for getting reading time estimates right.
Round up, never down, an underestimate disappoints readers more than a slight overestimate.
Adjust WPM by content type, technical docs need 150 WPM, casual posts can use 250+.
Add time for images and tables, word count alone understates true engagement time on visual content.
Scan the live DOM, not static values, so the estimate stays accurate as content is edited.
Show it near the title, readers decide whether to commit before they start scrolling.
200-250 WPM covers most general blog content. Use 150 WPM for technical documentation, and up to 265 WPM (Medium's standard) for casual, easy-to-read posts.
Yes. Research shows displaying reading time on blog posts can increase engagement by around 30%, since it helps readers commit with clear expectations upfront.
Round up using Math.ceil(). Underestimating disappoints readers who expected a shorter read, while a small overestimate rarely causes a problem.
Yes, meaningfully. Each image adds roughly 12-20 seconds of viewing time, and ignoring this can noticeably understate true reading time on image-heavy posts.
Research from Medium found posts around 7 minutes (roughly 1,855 words at 265 WPM) achieve the highest engagement, though this varies by content type and audience.
Reading Time = Word Count ÷ Words Per Minute
WPM should vary by content type, not stay fixed
Images add real, measurable time beyond word count alone
Displaying reading time can lift engagement by around 30%
Always round up to avoid disappointing readers
Scanning the live DOM keeps estimates accurate as content changes
Reading time pairs well with table of contents generation for long-form content. Explore both guides next.









