For raw output, dictation wins by a wide margin: average speech runs 130-150 words per minute, average typing around 40. But that gap shrinks once you factor in the time spent fixing transcription errors, restructuring rambling sentences, and hunting for the right punctuation command. For first drafts, brain dumps, and message replies, dictation is still faster start to finish. For code, precise formatting, or anything requiring heavy backspacing, typing wins outright.
The 130-150 vs 40 wpm comparison gets quoted constantly, and it's true as far as it goes — but it measures the wrong thing. It measures how fast words leave your mouth or fingers, not how fast a finished, readable document lands on screen.
Typing has a built-in editing loop: you see the mistake, you backspace, you fix it, and the correction cost is already baked into your effective wpm. Dictation front-loads speed and back-loads correction. You might blast out 400 words in three minutes, then spend five minutes fixing homophones, misheard technical terms, and the run-on sentence structure that spoken language naturally produces. The real comparison isn't wpm — it's minutes-to-finished-paragraph, and that number depends entirely on what you're writing.
Speech is faster to produce and, for certain content types, faster to clean up too. Three cases where dictation comes out ahead even after correction time:
First drafts and brain dumps. When you don't know exactly what you want to say yet, typing speed doesn't matter — thinking speed is the bottleneck, and thinking happens faster in speech than in typed sentences you're simultaneously editing as you go. Dictating a rough draft and cleaning it up afterward is usually quicker than composing carefully at the keyboard the first time.
Replying to messages. Slack threads, emails, code review comments — conversational text that doesn't need precise structure. Say it, glance over it, send it. The correction overhead on a three-sentence reply is seconds, not minutes.
Long narrative writing. Journaling, meeting notes, documentation drafts, blog post skeletons. You're producing prose, not manipulating symbols, and prose is what your voice is built for.
The mechanics matter here too. Voxtty runs on-device using faster-whisper with voice activity detection, so it only transcribes when you're actually speaking — no lag waiting for a server round-trip, no dead air burned waiting on an API response. Press Alt+D, talk, the words land in whatever app has focus. Because it's local, there's no network latency added to your correction loop, which matters more than it sounds like it should when you're doing rapid dictate-check-fix cycles. An optional, opt-in cleanup pass can strip filler words from the transcript text afterward, cutting down on the "um, so basically, uh" cleanup that spoken language always needs — that step sends only text, never audio, to the Claude API. Try Voxtty free if you want to test this on your own writing instead of taking the wpm numbers on faith.
Code is the obvious one. Variable names, brackets, indentation, and exact syntax don't survive speech-to-text well, and no amount of correction-loop efficiency beats just typing `const x = []` directly. Precise formatting — tables, nested lists, anything with exact spacing or symbols — has the same problem: describing structure out loud is slower than just building it.
Dense technical writing with a lot of jargon, acronyms, or domain-specific terms also tips back toward typing, because that's exactly where Whisper-based transcription (local or cloud) makes the most mistakes, and every mistake costs you a correction pass. If your draft is going to be 30% proper nouns and API method names, you'll spend more time fixing transcription errors than you saved by talking instead of typing.
On-device transcription is not going to match top-tier cloud speech-to-text on raw accuracy, particularly with strong accents, fast speech, or a noisy room — a Whisper model running locally on a laptop CPU is working with less compute than a cloud API backed by a GPU cluster. If your accent or vocabulary sits outside what the training data covered well, expect a higher correction rate, which eats directly into the time savings this whole comparison is built on.
Background noise is the other big variable. A quiet room gets you close to cloud-level accuracy; a busy open-plan office or a train will produce noticeably more misrecognitions, and VAD can only do so much to separate your voice from a barking dog or a loud aircon. And if you're on Wayland, dictation-to-keystroke tools generally depend on `ydotool`, which needs a bit of setup most distros don't ship configured out of the box.
Pick one piece of writing you'd normally type from scratch — a status update, a long email, a rough outline — and dictate it instead. Time yourself from start to a version you'd actually send, correction included. That number, not the 130-150 wpm headline figure, is the one worth comparing against your typing speed.
Local-first voice dictation for Linux. Press Alt+D, speak, and your words land in whatever app has focus — nothing leaves your machine.
Try Voxtty free →