Remove filler words from dictated text (not video)

If you're dictating text — an email, a note, a prompt to an AI coding agent — and you want the "um"s and "uh"s gone, you're not looking for a video editor. Every tool that ranks for "remove filler words" works by turning a recorded audio or video file into an editable transcript, then letting you cut disfluencies from a timeline after you've stopped talking. Dictation doesn't work that way: the text lands at your cursor the moment you stop speaking, with no recording to go back and edit.

For dictated text, filler words have to be handled at the transcription step itself — either by a speech-to-text model that already skips them, or by a cleanup pass that runs immediately after transcription, before the words ever reach the page. Neither is what the ranking "filler word remover" tools do.

Does Whisper transcribe "um" and "uh"?

Sometimes, and not because it's designed to skip them. Whisper's training data went through a text-normalization pass described in OpenAI's original Whisper paper (Appendix C, "Text Standardization"), and independent research on Whisper's behavior with disfluent speech confirms the side effect: the team behind CrisperWhisper, a fork built specifically for verbatim transcription, found that standard Whisper "eliminates many filler words, recurring utterances and other artifacts" as "an intended transcription style, suitable for contexts where clarity of intent is prioritized over detailed speech analysis" (arXiv:2408.16589).

That sounds like a feature. It isn't a reliable one. On OpenAI's own Whisper repository, the documented workaround for people who want filler words kept is to prime the model with a prompt that already contains disfluencies — "Umm, let me think like, hmm..." — which nudges it into expecting them (github.com/openai/whisper/discussions/1174). And the failure mode cuts both ways: a 2025 study on Whisper and disfluent speech found the model doesn't always drop a filler cleanly — it can fold a dropped "uh" into the next word and mistranscribe it outright, turning "uh distinct" into "staked" in one recorded example (arXiv:2505.21551).

So: Whisper's output is filler-light some of the time, as a byproduct of its training data, not because it's running a cleanup step. That's an accident, not a workflow you can build on.

Why doesn't Descript or Premiere Pro help with dictation?

Search "remove filler words" and the results are unanimous — every tool that ranks is built for editing a recording after you've stopped talking. Descript's Remove filler words feature turns your audio or video into an editable script: it flags each "um" and "uh" and lets you delete, ignore, or replace it, currently for English, German, French, Portuguese, and Italian tracks. Adobe Premiere Pro's Filler Word Detection does the same job through its text-based editing panel, letting you bulk-delete filler words and pauses straight from the transcript (RedShark News). Riverside built a whole feature, Smooth Speech, around the same idea for podcast and video hosts (Riverside's own walkthrough), and Opus Clip's roundup of the "10 best filler-word removers" is a list of exactly these tools (opus.pro). Ask r/podcasting for recommendations and the answers are the same shape — Murf, Cleanvoice, Descript — all built around a recorded file (reddit.com/r/podcasting).

None of that applies if you're dictating an email, a Slack reply, or a voice prompt to an AI tool. There's no timeline to scrub and no transcript-as-document to edit afterward — the text has to land clean at your cursor, in real time, or it doesn't get cleaned at all. That's the actual gap: the whole "remove filler words" category was built for people editing finished recordings, and none of it covers someone just trying to talk instead of type.

What does an extra "um" actually cost when you're prompting an AI?

Here's a prompt someone might dictate into a coding agent: "So, um, can you, like, refactor this function, uh, to use async await instead of callbacks?" That's 17 words, three of which — "um," "like," "uh" — carry zero instruction.

Using OpenAI's own tokenizer guidance, one token is roughly ¾ of an English word (platform.openai.com/tokenizer), so three filler words compress to about 4 tokens. At Anthropic's current published rate for its cheapest model tier, Claude Haiku 4.5, of $1 per million input tokens (docs.anthropic.com/en/docs/about-claude/pricing), those 4 tokens cost about $0.000004. Genuinely nothing, once.

Except a prompt is rarely sent just once. The Claude API, like every major LLM API, is stateless: each request carries the entire conversation so far, not just the newest message. If those three filler words land in turn one of a 40-turn coding session, they ride along — re-billed — in the input payload of the other 39 turns too. That turns one dictated "um" into roughly 160 tokens of pure noise across a single session, still a fraction of a cent, but repeated across every dictated prompt, every session, every day, for anyone who talks to an AI more than occasionally.

The honest number is small. The honest point is different: it's 100% waste for 0% benefit, sitting in a context window that has a finite budget no matter how large the model's limit is. And unlike almost every other inefficiency in a prompting workflow, this one costs nothing to fix — because it never has to exist in the first place. It's created at the exact instant a microphone turns sound into text, which means it can be caught at that exact instant too.

How do you actually remove filler words from dictated text?

For recorded audio and video, the post-production tools above genuinely work — if you're editing a podcast or a YouTube video, use them. For live dictation, there are really only two levers:

• A transcription model tuned to skip disfluencies. This is what Whisper already does some of the time, inconsistently, as a byproduct of its training data rather than a designed feature — not something you can switch on or depend on.
• A cleanup pass that runs after transcription and before the text lands. A small model reads the rough, spoken-style output and rewrites it into clean prose: strips filler words, closes off false starts, tightens run-on sentences.

Inkvox handles the first half of that pipeline today: dictation runs 100% on your own machine, with Whisper large-v3-turbo (quantized) on your GPU through Vulkan — NVIDIA, AMD, or Intel — transcribing a sentence in roughly 0.3–0.4 seconds on hardware like an RTX 3070. Zero bytes uploaded, no account required. See how it works.

The second half — the cleanup layer — is what we're building for Inkvox Pro: a local LLM rewrite pass, running on the same GPU, that addresses exactly the mess this article is about — filler words, false starts, rambling — before the text ever leaves your machine. It's in active development, not shipped yet. When it lands, dictating a prompt into your coding agent or drafting a message full of "um, so basically" won't mean typing "um" into the tool that was supposed to save you from typing at all.

FAQ

Does Whisper remove filler words automatically?

Not reliably. Whisper's training data went through a text-normalization step that makes it drop many filler words as a side effect, not because it runs a cleanup pass. Research on Whisper's behavior confirms this is inconsistent — the model can also fold a dropped "uh" into the next word and mistranscribe it.

Can Descript or Premiere Pro remove filler words from dictated text?

No. Those tools remove filler words from a recorded audio or video file by turning it into an editable transcript or timeline you scrub after the fact. Dictation writes text straight into an app in real time — there's no recording or timeline to go back and edit.

Do filler words cost extra tokens when you dictate a prompt to an AI?

Yes, though the amount per prompt is tiny — each filler word is roughly one token. The bigger issue is that LLM APIs resend the full conversation on every turn, so filler words spoken early in a session get billed again on every later turn.

How do you clean up dictated text before it lands, instead of after?

Today, that means using a transcription model that already skips some disfluencies where it can. The more reliable fix is a dedicated rewrite pass that runs immediately after transcription, before the text reaches the page — the local cleanup layer Inkvox is building for Pro.

The filler words aren't the real problem — typing them, or paying to have a model read them, is. Fix it at the source and there's nothing left to clean up. Join the waitlist to try dictation that skips the mess in the first place.