Voice dictation vs typing — the actual speed gain (with the math)

Voice dictation marketing always quotes the same number: "3× faster than typing!" The truth is more interesting and less universally impressive. Here's what the speed gain actually looks like across the kinds of writing knowledge workers do all day — and where dictation loses to a keyboard.

The starting numbers

• Average typing speed: 40 WPM
• Fast typist: 75-90 WPM
• Court reporter (stenotype): 225 WPM
• Conversational speech: 140-160 WPM
• Confident dictation (after some practice): 160-180 WPM

So pure speaking outpaces fast typing by about 2×. That's the raw input rate. But raw input rate isn't what matters — output rate is. What actually lands on the screen, ready to ship.

Where the raw speed gain leaks

Filler words and self-correction

When you speak, you say "um," "uh," "like," "you know," and you stop mid-sentence to restart. Without AI cleanup, your 160 WPM transcript contains 30% padding that you'd have to remove by hand. Net editing time: high.

With AI cleanup, this leak closes — the cleanup model strips the filler and applies your self-corrections automatically. You get the 160 WPM net.

Punctuation

Speech doesn't have commas. The cleanup model has to infer them. Modern models do this well 95% of the time — the 5% wrong rate is your edit burden. For most non-fiction prose this is a ~1-minute edit pass per 1,000 words.

Code, formulas, formatting

Saying const handler = (req: Request, res: Response) => { } takes longer than typing it. Speech can't say a curly brace concisely. Dictating code is the wrong tool for the job — voice loses badly here.

Tab-completion-heavy work

When you're 4 letters into a variable name and your IDE is offering the completion, voice loses. The keyboard is dominant for code, autocomplete forms, and any interface where keystroke shortcuts compound.

Real-world speed gain by task type

Here's what we see in our own usage logs and what gets reported by teams who track this carefully. Numbers are the multiplier you'd expect — net of editing time, including AI cleanup, on a competent dictator with a tuned snippet library.

• Slack / Teams messages: 2.5-3× faster. Short messages, low complexity, voice dominates.
• Email body (3-5 paragraphs): 2-2.5× faster. The bulk of an email is prose — exactly where voice wins.
• PR descriptions, Linear tickets: 2-2.5× faster. Heavier structure but still mostly prose.
• Blog post first drafts: 2-2.5× faster for the first draft. Editing time on a draft is similar either way.
• Doc and meeting notes: 1.8× faster. Hands-free mode helps here — you can speak through a 10-minute summary without breaking concentration.
• Customer support replies: 2.5-3× faster. High volume, formulaic, voice + snippets compound.
• Code: 0× to 0.5× faster. Slower. Use the keyboard.
• Spreadsheets and forms: 0× to 1×. Similar to code — voice doesn't navigate fields well.

The right way to read this: voice typing is about 2× faster for the 70-80% of a knowledge worker's day that's prose. For the rest, you're on the keyboard. The split nets out to roughly 1.6-1.8× faster across an average day.

The fatigue compound

Raw WPM is hour 1. The hidden gain is that voice doesn't fatigue your hands. By hour 6 of typing, your speed drops 15-25% and your error rate climbs. Voice dictation stays at hour-1 speed for hours 4 through 8 because your hands aren't doing the work.

If you ship at the end of a long day, dictation effectively extends your high-output window by 2-3 hours.

Why "165 WPM" is misleading

Almost every voice-dictation marketing page quotes 160+ WPM as proof of speed. The number is real. But:

1. WPM is raw transcription rate, not finished-prose rate. You'll be editing.
2. It only matters on tasks where you'd otherwise sustain 75+ WPM typing. Most people don't, sustained.
3. It compares against your fast typing day, not your average. The voice number is consistent; the typing number isn't.

The honest number for most users is "2× faster on prose, breaks even or loses on structured text." That's still huge for the prose 70-80%. But it's not 3× across the board.

How to maximize the gain

• Use the right tone preset. "Casual" for prose drafts. "Email" for correspondence. "Slack" for chat. "Code comment" for JSDoc. The cleanup output changes meaningfully between them — getting it right means less editing.
• Build a snippets library. If you say "my email" 5 times a day, a snippet collapses 10 seconds × 5 = 50 seconds. Multiply by 20 snippets and you save real minutes daily.
• Use hands-free mode for long form. Holding a key for 60 seconds is annoying. Tap-on / tap-off lets you talk through a whole email without thinking about the keyboard.
• Don't try to dictate code. It's the bait everyone falls into. Keep voice for prose; keep the keyboard for syntax.
• Treat the first week as practice. Your edit-time drops 30-40% as you learn to trust the cleanup. The first 5 posts you'll over-edit; by post 10 you'll ship the cleaned output as-is.

The real productivity number

If you write 4-6 hours a day (typical for engineers, product managers, sales reps, lawyers, consultants), dictation collapses that to about 2.5-3.5 hours. That's 1.5-2.5 hours back in your day — every day, forever.

At a $200K total compensation, that's about $25-40k a year in productivity recovered. At $9.99/mo for the tool, the ROI is roughly 200-300×. Even if the speed gain is "only" 1.4× (more pessimistic than our data), the math still trivially favors using it.