A recording with long dead-air pauses and a string of "um" and "uh" sounds unpolished, even when the actual content is solid. Before you send an interview answer, a meeting recap, or a client demo, it is worth tightening the pacing so the listener's attention stays on what you're saying, not on the gaps between sentences.
You do not need a professional editor or desktop software to do this. A browser-based tool can scan the audio track, flag the silent stretches and repeated filler sounds, and let you review each suggested cut before anything is actually removed.
Tighten recorded answers so pauses don't read as hesitation to a hiring panel.
Trim dead air from a recap before sharing it with people who weren't on the call.
Keep a product walkthrough moving so viewers don't drop off during a long pause.
No upload, no signup. Detection runs with the Web Audio API and trimming runs through FFmpeg compiled to WebAssembly, entirely in your browser.
Clean Up My Recording →Every microphone and room has a different noise floor. A sensitivity slider lets you tell the tool what counts as "silence" in your specific recording, instead of relying on one fixed threshold that works for some voices and not others.
Automatic filler-word tagging uses your browser's live speech recognition, which only works on a live microphone stream rather than an already-saved file. Recording directly inside the tool gets filler words tagged automatically; if you uploaded a file, you can still mark extra cuts manually in the same preview list.
If you recorded your clip with the Video Messenger tool, export it first, then run that export through the Silence & Filler Word Remover for a tighter final cut before you send it along.
An automatic trimmer does not listen for words. It decodes the audio into raw samples, scans them in short windows of a few milliseconds each, computes an RMS amplitude for every window — a fair approximation of perceived loudness — and compares it against a threshold.
That single fact explains nearly every surprising result. A pause recorded with an air conditioner running is not quiet in signal terms, so it will not be cut. A whispered word can be quieter than the room, so it may be. If the tool keeps a gap you expected it to remove, the gap was not actually silent; if it clips a word, that word fell below the noise floor.
| Control | Raise it when | Lower it when |
|---|---|---|
| Silence sensitivity | The room is noisy and real pauses survive | Soft consonants or quiet speakers get clipped |
| Minimum silence length | The result feels choppy and breathless | You want tight, fast-cut social pacing |
| Minimum gap to keep | Words are colliding into each other | You want maximum compression |
The common default of 400 ms for minimum silence length is chosen deliberately. Natural speech contains clause pauses of roughly 150–300 ms and breath pauses of 300–600 ms. Push the minimum below about 250 ms and you start removing the grammatical pauses that make a sentence parseable, which is why over-trimmed audio can be exhausting to listen to even when nothing is obviously wrong with it.
A twelve-minute unscripted screen recording typically contains 90 to 140 pauses longer than 400 ms. If 110 of them average 700 ms and you retain 120 ms at each cut, the saving is 110 × (700 − 120) = 63,800 ms, about one minute four seconds. That is roughly 9% of the runtime, and it feels like more, because the removed moments are precisely where attention wanders. Genuine dead air — twenty seconds waiting for a build to finish — is where the technique really earns its keep.
Removing "um", "uh", "like" and "you know" is not the same task. Silence is a property you can measure directly from the waveform. A filler word is a linguistic category — you must recognise the word before deciding to delete it, which needs speech recognition, and know its boundaries to the millisecond, which needs forced alignment.
In practice most fillers sit between pauses, so silence trimming tightens them considerably as a side effect. Where a filler is fused onto the next word — "um-so-anyway" — no threshold separates them cleanly, and that is a manual edit. This is exactly what a reviewable cut list is for.
Errors cluster around a speaker's habits, so once you have spotted one you know what to look for. Scanning the shortest proposed cuts first surfaces problems quickly, because a false "silence" inside a word is almost always a short one.
Teaching content needs processing time after a new concept. Interviews need the gap between one speaker finishing and another starting, or people sound like they are interrupting. Anything with music or continuous ambience defeats the technique outright. And anything that will be subtitled later should not have its timing changed after the captions exist.
Files are read with the browser's File API and decoded locally; nothing is uploaded and nothing is retained. This matters more here than for most tools, because raw recordings are the least filtered material most people produce — false starts, names, internal detail, things said in the belief they would be cut. Keeping that on your own device is a genuinely different privacy position from uploading it to a processing service. Verify it in the Network tab of developer tools, or disconnect from the internet after the page loads.
Around 5 to 12% of total runtime for unscripted talking-head or screen-recording content. Recordings with genuine dead air - waiting for loads, builds or page transitions - can drop 20% or more, because one twenty-second gap is worth many ordinary pauses.
Plosive consonants such as p, t and k begin with a silent closure, and many speakers drop volume at the end of a sentence. If that window falls below the threshold it reads as silence. Lower the sensitivity, raise the retained gap, or simply switch that individual cut off.
They are probably not quiet in signal terms. Air conditioning, fans, traffic or a music bed lift the noise floor above your threshold. Raise the sensitivity so more of the range counts as silence, or record somewhere quieter.
Not by itself. Identifying a spoken word needs speech recognition plus millisecond-accurate alignment, which is a different problem from measuring loudness. Most fillers sit between pauses and get tightened anyway; ones fused to the next word need a manual edit.
Leave the defaults - around 400 ms minimum silence and 120 ms retained - then preview. For a fast social clip try 250 ms and 80 ms. For tutorials go the other way, around 600 ms and 200 ms, which keeps the delivery breathable.
Teaching content, where pauses are processing time. Interviews, where the gap between speakers carries meaning. Anything with music or continuous room tone, where cuts produce audible jumps. And anything already subtitled, since timing changes invalidate the captions.
No. It is read and decoded entirely in your browser and nothing is transmitted or stored. Watch the Network tab in developer tools while processing, or disconnect from the internet after the page loads - it still works.