7
8 Comments

I Built a Reading Speed Tool That Stops Guessing Your WPM

I built MyReadingSpeed because most reading time calculators use one generic number (usually 200–300 WPM), which is often inaccurate.

Reading speed changes a lot by content type. Fiction, academic papers, technical docs, and legal text are not read at the same pace. So I made a tool that first measures your actual reading speed by genre, then uses that to estimate realistic reading time.

It’s free, no signup, and works directly in the browser.

If you want to try:

- Main tool: https://myreadingspeed.top/

- Genre benchmarks: https://myreadingspeed.top/average-reading-speed-by-genre

- Words-to-time table: https://myreadingspeed.top/words-to-reading-time-calculator

Would love feedback on accuracy and UX.

posted toAvatar for product MyReadingSpeed
MyReadingSpeed
  1. 1

    Clean idea. How are you handling different screen sizes affecting reading speed?

  2. 1

    This is a really smart approach. I’ve noticed my reading speed drops a lot with technical docs compared to blogs, but most calculators never account for that.

    One small suggestion: showing a confidence range (like “5–7 min” instead of exact time) might feel more realistic, since focus also changes day to day.

    Tools like this are especially useful for students and researchers planning their reading workload.

  3. 1

    Where's the reading speed is used for? i mean for what purpose? You have a niche product which is trying a solve one particular thing. Are there any reading speed competitions in world?? which could use this?

  4. 1

    How long did it take you to feel confident about your startup’s positioning, and would you pay for a tool that helped you get there in under an hour?

  5. 1

    Simple, focused tools like this are underrated. Everyone wants to build the next all-in-one platform, but sometimes solving one specific problem really well is the better play.

    What's been your biggest challenge in getting people to discover it? For single-purpose tools, distribution is often harder than building the product itself.

  6. 1

    This is actually a smart problem to solve — the 200 WPM default has always felt like a made-up number someone picked decades ago and everyone just ran with it. The genre split makes total sense, especially for anyone doing research or working through dense technical docs where your brain is processing and re-reading constantly, not just scanning. One thing I'd be curious about — do you plan to add a "re-read factor" or comprehension layer at some point, since reading speed without retention context can still give a pretty optimistic estimate?

  7. 1

    Interesting breakdown. I’ve seen many early-stage founders underestimate legal and compliance risks when scaling. Proper structure early on can save a lot of time later.

  8. 1

    The genre split is the right call. I've noticed the same thing , I can fly through fiction but the same word count in a technical doc takes twice as long. A single WPM number never made sense.

    Curious what you used to calibrate the genre benchmarks. Self-reported data, or something else?