Reading Time Estimator
Estimate Markdown reading time — Medium-style, audience-aware
Calculate "min read" for any Markdown content with customizable WPM, image weight, and code-line weight. Copy a Markdown badge for your blog header. No tracking, no signup.
Default — engineering blog or docs
51 sec read
at 200 WPM
- Words
- 111
- Image time
- 12s
- Code lines
- 3
Total ≈ words / WPM + images × 12s + code-lines × 2s. Fenced code is excluded from the word count so prose ratios stay realistic.
How to use the reading time estimator
- Paste Markdown content, or click Open .md to load a file.
- Pick an audience that matches your readers — the WPM updates automatically.
- Tune seconds per image and per code line if your defaults don't fit (longer for complex screenshots, shorter for repetitive snippets).
- Copy the badge as a Markdown blockquote to drop into your post header.
What goes into the estimate
total seconds = round((words / wpm) × 60)
+ (images × seconds_per_image)
+ (code_lines × seconds_per_code_line)
Words are counted from the prose only — fenced code blocks, raw inline code, and image markdown are removed before the count so the prose ratio stays realistic.
Why publish a reading-time badge
- Sets expectations. A "12 min read" tag tells a busy reader whether to open now or save for later.
- Boosts completion rates. Posts with reading-time hints have measurably higher full-read rates in publisher analytics — readers commit when they know the time investment.
- SEO microdata. Some search engines surface reading time in rich results when the page exposes it in a clear way.
WPM cheat sheet
| Audience | WPM | When it fits |
|---|---|---|
| Deep / academic | 140 | Research papers, in-depth tutorials |
| Technical reader | 200 | Engineering blog posts, README content |
| Casual reader | 240 | Light blog content, marketing pages |
| Skimmer | 350 | Listicles, news, headings + first sentences |
Companion tools
- Markdown Word Counter — full stats including readability score.
- Markdown Frontmatter Editor — set the
readingTimefield for your static site. - Markdown to Plain Text — preview what a reader would actually consume.
Privacy & data
The estimator runs inside your browser. No content is uploaded.
Frequently asked questions
- We strip fenced code blocks from the word count, then divide by your selected words-per-minute speed. We add fixed time per image (default 12 seconds) and per code line (default 2 seconds) because both slow real readers down. The result is rounded to the nearest minute (or shown in seconds for very short posts).
- Reading speed varies a lot by audience. Engineering readers scanning a docs page move quickly (≈200 WPM). Casual blog readers are similar (≈240 WPM). Skimmers absorb headings and first sentences (≈350 WPM). Deep readers studying academic or reference material slow down (≈140 WPM). Picking the right audience produces an estimate readers actually trust.
- Yes — they break the prose flow. A 200-word post with five screenshots takes far longer than 200 plain-text words. The defaults (12s per image, 2s per code line) are conservative and well-supported by usability studies.
- The [Word Counter](/tools/markdown-word-counter) reports many stats including a single rounded reading-time number. This page is dedicated to that estimate: customize WPM and weights, see word / image / code contributions side by side, and copy a ready-to-paste Markdown badge.
- No. The calculator is pure client-side math. We don't upload, log, or store the Markdown you paste.
- For one-off estimates, use this page and paste the badge. For automated insertion in a static-site pipeline, the [`reading-time`](https://www.npmjs.com/package/reading-time) npm package implements the same algorithm and can run at build time.
How is reading time calculated?
Why customize the WPM?
Should images and code really add time?
How is this different from the word counter?
Is my content uploaded?
Can I auto-insert reading time into my blog posts?
Related tools
More free browser tools in the same workflow.
Use the API
Automate this workflow in your app with the same engine that powers these browser tools.
New to the platform? Start with the API quickstart, then try a live request in the API playground.
Explore the API platform