Filler words in speech-to-text: retained vs clean output

Every transcript you get back from a speech-to-text API has already made a decision about filler words. If you never set the filler_words parameter, the default decides for you, and it strips the two most common hesitation sounds, "uh" and "um". Seven small sounds fall under this one setting, and five of them do a different job.

Sounds like "uh-huh", "mhmm", and "uh-uh" let a listener signal yes or no without taking over the conversation. The docs show "uh-huh" surviving the default and stay quiet about the rest. A clean-looking transcript can therefore still carry a spoken yes, and whether it carries a spoken no is worth testing on your own model.

Where that matters is court records, clinical notes, meeting summaries, and anything you feed to a language model. In this guide, you'll see what each of the seven sounds means and what the default actually removes.

Before you accept the default, know what it does.

• filler_words is a boolean that defaults to false on Deepgram's Nova-family models.
• Five of the seven documented tokens are agreement or disagreement signals, not hesitation markers.
• The docs name only uh and um as stripped; the docs table confirms uh-huh passes through, while the other backchannel tokens remain unclassified.
• uh-huh and uh-uh look alike and can mean opposite things, so your downstream code must handle both.
• The federal Guide to Judiciary Policy protects verbalizations whose exclusion changes meaning; Arizona's transcript manual names uh-huh specifically; AHDI's Book of Style rejects verbatim.
• Coverage is language-limited, and the docs pages conflict on model support.

A filler word carries one of two signals, either that the speaker wants to keep the floor or that the listener agrees. Neither signal shows up in the words alone, so stripping the tokens takes that information with them.

You say "uh" and "um" while you're still working out how to finish a sentence. They tell the other person you're not done, so don't jump in yet. The signal is about timing, and it says nothing about what you mean.

The other five come from whoever is listening. They're how you answer without taking over the conversation, and recent work on how models handle these sounds describes them as carrying agreement or disagreement with what was just said. Strip one out and you've dropped a reply the listener actually gave.

Both jobs sit behind the same setting, and that's where the confusion starts. The 2023 announcement described the feature in terms of "um" and "uh", and the name points the same way. The list underneath it includes five sounds that do something else entirely.

Deepgram detects seven tokens, and the default strips two of them, uh and um. The filler words documentation defines filler_words as a boolean that defaults to false, and it leaves the default behavior of the other five unstated.

Deepgram's documentation lists them in this order: uh, um, mhmm, mm-mm, uh-uh, uh-huh, and nuh-uh. The docs present the full set as tokens this parameter governs. They don't explicitly classify mhmm, mm-mm, uh-uh, and nuh-uh at the default setting.

Leave the parameter unset, or set it to false, and the docs say the two most common fillers come out of the transcript for readability. Those two are "uh" and "um", and they're the complete removal list. Nothing in the documentation names the remaining tokens as stripped.

No matter how long a speaker holds a sound, the transcript spells it one way. The docs are explicit here: the listed spellings are the only ones you'll get back, whatever the spoken duration. A drawn-out "uhhhh" still comes through as "uh". If you pattern-match transcript text, this matters. The fixed spellings suggest an exact-match filter against the listed forms should generally suffice, without fuzzy matching.

Only uh and um mark a speaker stalling for time. The remaining five tell you whether someone said yes or no. Turning filler_words on does more than preserve verbatim style. It's how you capture a spoken yes.

Two of the seven are speaker-side hesitation markers, uh and um. The other five are backchannels: mhmm, mm-mm, uh-uh, uh-huh, and nuh-uh. uh-huh and mhmm can read as assent, though they often mark only continued attention. Research on clinical conversations pairs mm-hm and uh-uh as the sounds patients use to answer yes and no, and treats them as carrying information the chart depends on.

Texas courts tell their reporters much the same thing in a formatting manual, which spells a negative answer as huh-uh. The negative side therefore has support outside the vendor docs, which assign no polarity to any of the seven, nuh-uh included, though that spelling patterns with the negatives.

The Results table on that same docs page makes it visible. Its "Without Filler Words" column still opens with uh-huh even though every uh and um has been stripped. Only uh-huh is directly demonstrated at the default, so the documentation doesn't establish the behavior of the other backchannel forms. T

est the unclassified forms on your selected model. You might read the default as suppressing the whole set. The docs table shows otherwise for uh-huh. What the default buys you is clean hesitation handling, not necessarily a transcript free of non-lexical tokens.

Read them side by side, and uh-huh means yes while uh-uh means no, one letter apart. mhmm and mm-mm sit nearly as close. We found no published study documenting a language model flipping polarity on these spellings.

Treat this as a hazard you reason about from the orthography, not a documented failure mode. It still deserves a test case in any pipeline that infers agreement from text.

You need filler_words=true when a court record, a research corpus, or a coaching product depends on the tokens. Federal court policy requires them whenever meaning turns on them. Retaining the documented seven still doesn't satisfy every requirement of a governing verbatim standard.

The federal Guide to Judiciary Policy lets transcribers drop hesitation sounds for readability, with one hard limit. Any such verbalization has to be transcribed when leaving it out could change what a statement means.

Arizona's transcript manual goes further. Dropping an uh-huh that was used to express assent counts there as a major verbatim error. Clinical documentation points the other way. The Association for Healthcare Documentation Integrity's Book of Style says plainly that the group doesn't endorse verbatim transcription. A readable clinical record is the goal there, which is what the default already produces.

If you're building for conversation analysts or speaking coaches, those tokens are the data your users pay for. A coach counting hesitations per minute, or a researcher coding listener feedback, gets nothing when the markers are removed upstream. Speaking coaching and legal transcription were both named as target use cases in the launch post.

A spoken uh before a required disclosure may fall under the federal meaning-change rule above, which covers verbalizations. If your review process turns on that kind of evidence, set the parameter to true.

Keeping the tokens can help the machine too. One 2025 transcription experiment found that training on real "um" and "uh" labels beat stripping them, cutting word error rate by about 11 percent. Downstream tools show the same sensitivity. A summarization model trained on tidy text lost up to seven points of overlap with its reference once the input included repeats and restarts.

You want the default for captions, call recaps, clinical notes, and anything feeding a language model. It gets you there without touching the request. Your pipeline may still receive backchannel tokens.

If you're building captions, call recaps, or searchable archives, readers usually want what was said. The stripped tokens mark speaker planning instead. Pair the default with Smart Formatting for punctuation.

Only the launch announcement pairs the features, so check the combination on your own audio before shipping it. Clinical documentation is another use case for clean output, per the AHDI position above.

Retained uh-huh and mm-mm arrive as plain text in your language model. Your application must therefore handle retained tokens. A prompt instruction can do so, while preprocessing can either filter the tokens or map each one to yes or no.

Model behavior on non-fluent input is worth measuring rather than assuming. One test of podcast summarizers saw scores fall by about 24 percent when repeats, interjections, and false starts all appeared together.

The default removes the hesitation markers. The docs directly show uh-huh retained but leave the other backchannel spellings unclassified. Any downstream string matcher, intent router, or agreement detector should account for every documented backchannel spelling your selected model retains. Write them into test fixtures before a spoken no gets scored as a yes.

Test production coverage before deployment on your exact model because Deepgram's pages don't fully agree with each other.

The feature page limits filler words to the Nova, Nova-2, and Nova-3 general models. But the Flux and Nova-3 comparison table marks Nova-3 as unsupported while listing Flux support. The models overview recommends Nova-2 for filler word identification. The documentation doesn't reconcile these statements.

Unlike Punctuation and Smart Formatting, which cover all languages, the pre-recorded feature overview lists this feature for English (all available regions) only. If you ship in more than one language, you'll need a different plan for non-English audio.

Run the same audio file through your production model with the parameter on and off, then diff the output. Confirm current coverage against the docs before deployment. The conflicts above are exactly why.

Where the transcript ends up decides the setting. Write the choice into your request so the next engineer sees a decision, not an omission.

Each row below pairs a destination with the setting it calls for.

If your product spans two rows, choose the setting that keeps more, because you can strip tokens downstream but you can't recover them.

Append filler_words=true to your request query string, the way the docs example pairs it with model=nova-3. If your product also takes spoken punctuation commands, Dictation formatting is a separate feature that requires punctuate=true. The docs record no interaction between the features.

Read the diff before you let the default decide for you. Create a free Deepgram account and put your $200 free credits against your own audio.

Current developer docs say nothing about either. The launch post claimed no latency impact and no added charge, but neither claim appears in current documentation. Current rates are on the Deepgram pricing page.

The launch announcement claimed diarization compatibility. No current feature page documents how retained backchannel tokens get attributed across speaker labels. A listener's uh-huh assigned to the wrong speaker reads as that speaker agreeing with themselves. Test the exact combination you plan to ship.

The filler-words documentation doesn't specify how unsupported models respond. Test the model you plan to use. Inspect the HTTP status, response body, warnings array, and output instead of assuming how the API will respond.

Yes. Match whole tokens rather than substrings, and preserve speaker labels while changing transcript text. Store raw and normalized transcript fields separately so you can audit or revise the filtering later.

Not clearly. Build a test matrix covering the model, streaming mode, punctuate, and filler_words settings. For each combination, record the HTTP response, warnings array, and transcript output before combining the features in production.