What WPM (words per minute) should I use for read time?

The standard for online content is 200-250 WPM, with 238 WPM being the median across 17 published reading-speed studies cataloged by Brysbaert (2019) and updated through 2024. Medium uses 265 WPM in its calculator; HubSpot uses 200; The New York Times reading time uses 200; Pocket uses 250. The right number depends on content complexity: simple narrative content reads at 250-300 WPM, technical content at 150-200 WPM, dense academic content at 100-150 WPM. For most blog posts and articles, 225-238 WPM produces estimates that match actual time-on-page within 15% accuracy. Don't use higher than 300 WPM — comprehension drops below 70% above that pace, which means readers won't finish or won't retain the content even if the calculator says they "could" read it. For audiobook-style content, narrate at 150-160 WPM (the audio standard); this is much slower than reading because comprehension constraints differ.

Does showing read time affect bounce rate?

Yes, in both directions depending on the number. Articles labeled "3 min read" through "8 min read" have 18-26% lower bounce rates than unlabeled articles, per Medium's 2018 internal study (still the most-cited dataset). Articles labeled "12+ min read" have 12-15% higher bounce rates because long estimates trigger reader self-disqualification. The implication: show read time on content under 10 minutes, hide or de-emphasize on longer content. For long-form content (>2,000 words), consider showing "Part 1 of 3 — 6 min" rather than "18 min total" to make the commitment feel more manageable. Some sites (The Atlantic, Vox) split long articles into chapters with per-chapter read times. Track your own bounce-rate by length-bucket in Google Analytics 4 to find your audience's threshold; it varies by topic and audience sophistication. Technical audiences tolerate longer read times than consumer audiences.

How does Medium calculate read time and is it accurate?

Medium's algorithm: 265 WPM base, plus 12 seconds per image. So a 2,000-word article with 4 images calculates as (2000/265) + (4 × 12/60) = 7.55 + 0.8 = ~8 minutes. The 12-second-per-image rule was set in 2014 based on Medium's telemetry of how long readers actually spent looking at images in articles. The accuracy is decent for narrative content but breaks down for: code-heavy technical posts (code reads slower than prose, often 50-70% of WPM), data visualizations (require longer engagement than 12 seconds), embedded video (whole-different-medium time, not "reading"), Twitter/social embeds (vary widely). For technical blogs (developer tutorials, engineering deep dives), use 175 WPM and add 30 seconds per code block to better match actual time. For visual content (design portfolios, photo essays), Medium's 12s/image is a fine baseline. Most read-time calculators inherit Medium's formula — accurate within 20% for most content, off by 50%+ for code-heavy posts.

Do I need to count images and videos in read time?

Yes for an accurate estimate. Images add 8-15 seconds each (Medium uses 12, but the right number depends on whether they're decorative or informational); informational diagrams and charts can take 30-60 seconds. Videos and embedded media add their full runtime if "play" is the expected interaction. Don't add time for purely decorative images (hero images, section dividers) — readers scan past these. The rule of thumb: count images that contain information the reader would want to study (annotated screenshots, comparison charts, code outputs) at 30 seconds; count images that contextualize the article (stock photos, brand illustrations) at 8-12 seconds. For embedded videos under 2 minutes, count the full runtime; for longer embedded videos, count 30-60 seconds since most readers scrub through. Code blocks: 30-60 seconds per block depending on length, since reading code requires comprehension overhead beyond prose. Our calculator includes optional adjustments for image count, video length, and code block count to produce more accurate estimates.

Is read time correlated with scroll depth?

Loosely, yes — but the correlation is weaker than expected. The 2024 Chartbeat study of 6 billion pageviews found average scroll depth peaks around 60-70% on most articles regardless of read time. Readers who finish 100% of an article rarely match the calculated read time; they typically skim faster than full reading allows. Readers who match the calculated read time often only scroll to 70-80%, finishing the article mentally but not visually scrolling to the end (many sites have lengthy footers, comments, related links). The implication: don't over-trust scroll depth as an engagement metric. Combine with time-on-page (Google Analytics 4 "Engagement time"), and read 100% scroll + full-time as "fully consumed" rather than just one signal. For pre-launch testing, ask 5-10 beta readers to read the article and report perceived time; their reported time often matches actual time better than scroll-depth measurement.

What's the ideal blog post length in 2026?

There is no universal ideal — the right length depends on search intent and audience. Comprehensive guides ranking for head-term keywords benefit from 2,000-3,500 words; quick answers ranking for question keywords benefit from 600-1,200 words. The 2024 Backlinko study of 11.8M Google search results found average page-1 result length is 1,447 words, with rankings 1-3 averaging 1,890 words. But length alone doesn't rank — content quality, freshness, and intent match matter more. Don't pad short content to hit 2,000 words; readers and Google detect padding within seconds. Don't cut long content arbitrarily to hit a "shorter is better" goal; comprehensive content earns long-tail traffic that compounds. Track your own content's reading-completion rate (via Hotjar or Mouseflow) to find the length where readers drop off. For most B2B content, 1,200-2,000 words; for B2C narrative, 800-1,500; for technical tutorials, however long the tutorial actually takes (don't pad).

Does read time affect SEO rankings?

Indirectly. Google doesn't use read time as a direct ranking signal, but it influences related signals that do affect rankings: dwell time (time on page after click from SERP), bounce rate (return to SERP within 30 seconds), and engagement time (GA4 metric used in some Google Ads quality signals). Pages with realistic read-time labeling tend to have better dwell time because readers are appropriately calibrated for the commitment. The 2024 SERP study by Semrush found pages with read-time labels averaged 23% higher dwell time than unlabeled pages at similar word counts. The mechanism: setting expectations (read time label) reduces the surprise-bounce of readers who expected a quick answer and got a long article. For SEO-driven content, label read time accurately, write to the displayed length (don't pad), and structure with subheadings to support both deep readers and skimmers. Skimming-friendly structure also helps featured snippet eligibility for question-style queries.

Should I show read time on all content?

For articles, blog posts, tutorials, and long-form content: yes. For listicles, FAQs, news updates, and quick-reference content: no. Read time labels work when readers are deciding whether to commit to a longer read; they're distracting on content where the format already implies short engagement. Specific recommendations: long-form articles always show read time near the title/byline. Listicles and how-to guides show "X items" or "X steps" instead — these are more useful framing. News and update posts skip read time entirely; they're consumed in feeds. Product pages skip read time; the page is for action, not reading. Tutorial content should show "X min read + Y min hands-on" since following along takes longer than reading. Email newsletters can show read time but it's less critical since readers have already committed by opening. Test on your own audience: A/B test articles with and without read-time labels and measure 30-day retention impact.

How do I make read time labels stand out?

Place the read time near the title and byline, in muted typography (smaller font, lower contrast than body text). The Medium pattern: "X min read · [Date]" in 14px gray text below the byline. Don't make it visually prominent — it's a contextual cue, not a primary navigation element. Use unambiguous formatting: "5 min read" not "5 min" (which could mean anything) or "00:05" (clock-time format implies video). For articles under 2 minutes, "Quick read" or "2 min" works fine. For very long articles (15+ min), consider "Long read" with the actual minutes adjacent. Some sites (Slate, Vox) use coffee-cup icons next to read time as a visual cue; this is fine but optional. Always pair read time with the publish date — readers consider both when deciding whether to invest. Don't round read time to "even" numbers like 5, 10, 15; specific numbers (3, 7, 12) signal genuine calculation rather than rounded marketing claim.

How does WPM vary by language and demographic?

WPM varies significantly by language, with English averaging 238 WPM for reading and 150 WPM for spoken delivery. Spanish is similar to English at 218 WPM; Mandarin Chinese reads slower in WPM but faster in characters-per-minute (~158 characters/min); German reads slower at 179 WPM due to longer compound words; Japanese is the fastest at 357 WPM partly because kanji compress meaning. For multilingual sites, calibrate WPM per language version of the content, don't use English's 238 globally. Demographically: ages 18-25 read at 240-260 WPM, 26-44 at 230-250, 45-64 at 210-230, 65+ at 190-210. Educational background also matters: doctoral-level readers average 320 WPM on academic text, vs 200 WPM for the general public. For broad consumer audiences, 225 WPM is a safe middle estimate; for technical or expert audiences, 200-225 WPM accounts for content-density slowdowns.

How does this compare to Medium's built-in calculator?

Medium's built-in calculator is auto-applied to all Medium-published content using the 265 WPM + 12 seconds per image formula. It's not exposed for other use; you can't import a non-Medium article and get Medium's calculation. Our calculator is free, web-based, and accepts pasted text or word counts directly with adjustable WPM (200/225/250/275/300), image count, video count, and code block count for more accurate estimates on technical content. We also produce HTML output you can paste into your blog template, plus suggested labeling format ("X min read"). Medium's formula is fine as a default; our tool is more useful when you're publishing on a non-Medium platform (WordPress, Ghost, Substack, custom Next.js site) and want consistent read-time labeling across your content. For Medium-only authors, no migration needed — Medium handles it.

Should read time be calculated client-side or server-side?

Calculate at build/publish time, not at runtime. The word count of an article doesn't change after publishing, so the read time is a static value that should be computed once and stored. Avoid client-side JavaScript that re-counts on every page load — that's wasted compute and adds layout shift if the time appears after initial render. Implementation: compute read time when ingesting/publishing the article, store as a frontmatter field (read_time: 7), render it in the page template. For headless CMS systems (Sanity, Contentful, Strapi), add a read_time field that auto-populates from word count via a webhook or transform function. For Markdown-based blogs (MDX, 11ty, Hugo), use a build-time plugin like remark-reading-time or hexo-reading-time. Static computation also makes the read time available in social-share previews and email newsletters where dynamic JavaScript can't run.

Free SEO Tool

Free Read Time Calculator

Calculate read time for any text. Word count, average pace, mobile vs. desktop. Free, instant.

4.6on G2

4.8on Trustpilot

Used by 25,000+ marketers

What this tool does

Read Time Calculator delivers fast, reliable results for calculate read time for any text. word count, average pace, mobile vs. desktop. .

Designed to fit into your existing SEO and content workflow with no setup overhead.

How to use it

Five steps.

Paste your text or word count

Paste the article text directly, or enter the word count if you already know it — supports both inputs.

Pick a WPM rate

Choose 200 (technical), 225 (general), 250 (narrative), or 275 (light content) based on your audience and content density.

Add image and code counts

For image-heavy posts, add the image count (12 sec each); for technical content, add the code-block count (30 sec each).

View calculated read time

See the suggested label format ("X min read") plus the calculation breakdown so you understand the math.

Copy and paste into your blog

Use the copy button to paste the label near your article title and byline; recalculate whenever the article is meaningfully edited.

When teams use it

Six common workflows.

Blog publishing on WordPress or Ghost

A blog publisher needs accurate read-time labels per article that match actual reader engagement, with adjustments for image-heavy and code-heavy content beyond Medium's default formula.

Newsletter writer optimizing for retention

A Substack or newsletter writer needs to set accurate "X min read" expectations in email previews to reduce open-and-bounce behavior, calibrating per-article based on actual length and embedded media.

Technical blog with code-heavy tutorials

A developer blog publishing tutorials with 5-15 code blocks per post needs read time that accounts for code-reading slowdowns, producing labels like "12 min read + 4 min hands-on" rather than misleading short estimates.

Editorial team standardizing across authors

A 6-12 author publication needs consistent read-time methodology across writers using different platforms (Notion, Google Docs, Markdown), centralized via a single calculator that produces uniform output.

Content marketer generating internal docs

A content marketer producing internal training docs and onboarding content needs read-time estimates for course planning, helping employees budget time before clicking into long-form internal articles.

SEO-focused publisher tracking dwell time

An SEO-focused content team optimizing for dwell time and Core Web Vitals needs accurate read time to set reader expectations, reducing bounce-from-SERP behavior for under-disclosed long-form content.

Platform guides

Integrate with major platforms.

WordPress

Calculate read time in Grigora's tool from your article text or word count.
Paste the resulting "X min read" label into a Custom Field on the post.
Display in the theme template via the_field("read_time") or similar.
For automation, install Reading Time WP plugin or add code to functions.php using str_word_count and ceil.
Verify the label appears on published posts.

Ghost

Ghost auto-calculates reading time using its built-in 275 WPM algorithm.
For more accurate estimates, override via the Editor > Post Settings > "Reading Time" field.
Calculate the override value in Grigora's tool with your preferred WPM.
Save the post and verify the time displays on the live URL.
Repeat for image-heavy or code-heavy posts where Ghost's default underestimates.

Next.js / MDX blogs

Install remark-reading-time as an MDX plugin.
Configure WPM in the plugin options (default 265, recommend 225 for technical content).
The plugin injects readingTime into MDX frontmatter at build time.
Render in your blog template: <span>{frontmatter.readingTime} min read</span>.
For one-off corrections, override via frontmatter: readingTime: 12 in the .mdx file.

Substack

Substack does not auto-calculate read time.
Calculate manually in Grigora's tool from the published draft word count.
Paste the label ("8 min read") into the email subject preheader or top of the post.
Apply consistently across all posts to set audience expectations.
Track open-rate and read-completion in Substack's analytics to validate calibration.

Notion (publishing via Super or Potion)

Calculate read time in Grigora's tool from the Notion document word count.
Add a "Read Time" property to the Notion database.
The static publishing tool (Super, Potion, Feather) renders the property automatically in the published page.
Update the property whenever the document changes meaningfully.
Configure the publishing tool to show the property near the title.

Grigora vs. alternatives

Side-by-side.

Capability	Grigora	Tool A	Tool B	Free	Manual
Free tier available	Yes — unlimited	Bundled with Medium	Bundled with Ghost	Free CDN	Free WordPress plugin
Adjustable WPM (175-300)	Yes	Fixed at 265	Fixed at 275	Limited	Yes
Image adjustment (12s default)	Yes	Yes	No	Limited	No
Code-block adjustment for technical content	Yes	No	No	No	No
Works outside the host platform	Yes	No	No	Yes	WordPress only
Build-time integration via plugin	No (manual paste)	N/A	N/A	No	Yes (WP)
Pricing	Free	Free with Medium	Free with Ghost	Free	Free
Output ready for any platform	Yes	No	No	Yes	WordPress only

Common errors and fixes

Eight issues users hit.

Read time labeled but doesn't match actual length

Cause: Imported old read time after editing the article; never recalculated.

Fix: Recalculate read time on every publish/edit; automate via build-time plugin (remark-reading-time for MDX/Hugo).

Using 300+ WPM and overestimating speed

Cause: Picked a WPM number from a "speed reading" article instead of average reading studies.

Fix: Use 200-238 WPM for general content; comprehension drops sharply above 300 WPM and labels become unrealistic.

Read time on listicles or news posts

Cause: Applied read time to all content types.

Fix: Show read time only on long-form articles and tutorials; skip listicles, news, and short reference content.

Round numbers (5, 10, 15)

Cause: Manually estimated and rounded for aesthetics.

Fix: Use specific calculated numbers (3, 7, 12) — round numbers signal manual estimation, specific numbers signal genuine calculation.

No image or code adjustment for technical posts

Cause: Used Medium's 265 WPM formula on a tutorial with 8 code blocks.

Fix: Use 175-200 WPM for technical content and add 30-60 seconds per code block; technical readers slow down to comprehend.

Read time label too prominent

Cause: Designer styled it as a badge with high contrast color.

Fix: Mute the read time label — small text, low contrast, near the byline; it's a contextual cue not a primary element.

Read time without publish date

Cause: Showed only read time, no date.

Fix: Always pair read time with publish date; readers consider both when deciding whether to invest in the content.

Client-side JavaScript recalculation on every load

Cause: Implemented as runtime JS counting words on the rendered DOM.

Fix: Compute at build/publish time and store statically; runtime calculation wastes compute and causes layout shift.

Original data

2026 study.

238 WPM

Median reading speed across published studies (Brysbaert 2019)

18-26%

Bounce-rate reduction for articles labeled with read time

>30%

Comprehension drop above 300 WPM

+23%

Dwell-time uplift for read-time-labeled vs unlabeled (Semrush 2024)

Frequently asked questions

Twelve answers.

Related free tools

Other utilities.

Try Read Time Calculator now

Free, unlimited, no signup.

Try the Tool