I Built a Reading Time Calculator Because I Was Tired of Guessing

The Itch I Had to Scratch

Every time I finished writing a blog post, I'd do the same thing: paste it into a random word counter, then open a separate tab for a reading time estimator, then maybe copy it into Hemingway Editor for a readability check. Three tools. Three tabs. Same content.

That friction built up over months until I finally just... built one thing that does all of it.

That's how ReadMetric came to be.

Why This Problem Felt Worth Solving

Content creators obsess over SEO, formatting, and engagement — but reading time is one of those quiet signals that actually affects whether someone clicks "read more" on a platform like Medium or Dev.to. Studies have shown that readers self-select based on time commitment. Knowing your article is "4 min read" vs "12 min read" changes decisions — both for the writer and the reader.

I wanted a single tool that would tell me:

• Estimated reading time
• Word count
• Character count
• Sentence count
• Readability score (Flesch-Kincaid)

All at once, instantly, as I type.

The Tech Stack

I kept it lean. ReadMetric is a client-side web app — no backend, no database, no auth.

• Vanilla JavaScript for all the text parsing logic
• HTML + CSS with a clean, distraction-free UI
• Flesch-Kincaid algorithm implemented directly in JS for the readability score
• Hosted as a static site

The decision to go fully client-side was intentional. There's no reason your text needs to leave your browser. No API calls, no data retention, no account needed. You paste, you get your stats, you move on.

Technical Challenges

1. Reading Time Isn't as Simple as words / 200

The common formula — divide word count by average reading speed (roughly 200–250 WPM) — gets you close, but it breaks down for technical content. Code snippets, URLs, and heavily formatted text all affect perceived reading time differently than prose.

I ended up adding a toggle for "technical content" that adjusts the WPM estimate downward to account for slower reading through code-heavy material. A small thing, but it makes the estimate more honest.

2. Sentence Counting Is Deceptively Hard

Split on . and you'll catch decimal numbers, abbreviations, and ellipses as sentence boundaries. I went through a few iterations before landing on a regex that handles the most common edge cases without being brittle.

const sentences = text.split(/[.!?]+\s/).filter(s => s.trim().length > 0);

Still not perfect — nothing is — but accurate enough for practical use.

3. Readability Scoring Requires Syllable Counting

The Flesch-Kincaid formula needs syllable counts, and English syllable counting in code is... an adventure. There's no perfect algorithmic solution without a full dictionary lookup. I used a heuristic approach based on vowel groupings and common suffix rules. It's about 85–90% accurate on typical prose, which is fine for a "is this readable?" gut check.

Lessons Learned

Scope creep is real, even on solo projects. I started with just reading time and word count. Then I added character count "real quick." Then sentence count. Then readability. Each addition was small, but collectively they doubled the initial build time.

Users care about simplicity. The first version had too many options. I stripped it back to the core stats and got better feedback almost immediately.

Client-side-only is underrated. Not every tool needs a server. The performance is instant, the privacy story is clean, and there's nothing to maintain on the backend.

Try It

If you write blog posts, documentation, newsletters, or any long-form content, give it a spin:

👉 https://readmetric.getinfotoyou.com

Paste in your draft and see what comes back. No signup, no install, no catch.

Feedback welcome — especially if you hit edge cases with the sentence counter. That thing has humbled me more than once.

Built by a solo dev at getinfotoyou.com — a small portfolio of practical tools for writers and developers.