New tool • 100% Private

✂️ Silence & Filler Word Remover

Automatically find awkward pauses and filler words, fine-tune the sensitivity, preview every cut, and export a clean version — all processed locally with the Web Audio API and FFmpeg (WebAssembly). Nothing is uploaded.

🎤

1. Add your audio or video

Upload a file, or record straight from your microphone

📁

Click to choose a file, or drag it here

MP3, WAV, MP4, WEBM, M4A — processed entirely in your browser

or
Why record from the mic here? Browsers can only run live speech recognition on a live microphone stream, not on an already-saved file. So filler-word tagging ("um", "uh", "like"...) is available when you record in this tool. Uploaded files still get full silence detection and manual trimming.

Frequently Asked Questions

Does my audio or video get uploaded anywhere?

No. Analysis runs with the Web Audio API and the actual trimming/export runs through FFmpeg compiled to WebAssembly, both entirely inside your browser tab. Nothing is sent to a server.

How does silence detection work?

The tool measures the audio's loudness in small time windows and flags stretches that stay below your chosen sensitivity threshold for longer than the minimum silence length you set.

Can it remove filler words like "um" and "uh" from any file I upload?

Automatic filler-word tagging uses your browser's live speech recognition, which only works on a live microphone stream — not on a file that's already saved. Record directly in this tool to get filler words tagged automatically; uploaded files rely on silence-based trimming, and you can always mark extra cuts manually in the preview list.

Can I fix a cut if the tool gets it wrong?

Yes. Every detected cut appears in the manual review list where you can enable or disable it individually, then use "Preview With Cuts Applied" to listen before exporting anything.

What format is the exported file?

Video input is exported as .webm; audio-only input is exported as .mp3. Both play natively in modern browsers.

🔗

More Free Tools

What "Silence Detection" Actually Measures

The tool does not listen for speech. It measures loudness, sample by sample, and decides which stretches of the recording are quiet enough to be considered a pause. The audio is decoded into raw samples through the Web Audio API, then scanned in short windows — a few milliseconds each. For every window the tool computes an RMS (root mean square) amplitude, which is a fair approximation of perceived loudness, and compares it against a threshold derived from the Silence sensitivity slider.

This distinction matters because it explains almost every surprising result. A pause where the air conditioner is running is not silent in RMS terms. A whispered word is quieter than a noisy room. If the tool keeps a gap you expected it to cut, the gap is not actually quiet; if it cuts a word, that word was quieter than the background noise floor.

The Three Sliders, and What Each One Trades Away

ControlWhat it doesRaise it when…Lower it when…
Silence sensitivitySets the loudness threshold below which audio counts as silenceThe room is noisy and obvious pauses are being keptSoft consonants, breaths at the start of words, or quiet speakers are being clipped
Minimum silence lengthHow long a quiet stretch must last before it is eligible to be cut (default 400 ms)The result feels choppy or machine-gun pacedYou want tight, fast-cut delivery for social clips
Minimum gap to keepHow much silence is left behind after a cut (default 120 ms)Words are colliding and the speech sounds rushedYou want maximum compression and can tolerate a clipped feel

The default of 400 ms for minimum silence length is not arbitrary. Natural speech contains pauses between clauses that typically run 150–300 ms, and breath pauses that run 300–600 ms. Setting the minimum below roughly 250 ms starts removing the grammatical pauses that make a sentence parseable, which is why aggressively trimmed audio can feel exhausting to listen to even when nothing is obviously wrong with it.

A Worked Example

Take a 12-minute screen recording of a software walkthrough. A typical unscripted take of that length contains somewhere between 90 and 140 pauses longer than 400 ms — reading the next step, waiting for a page to load, thinking about phrasing. If the average removable pause is 700 ms and 110 of them are cut with 120 ms retained each, the arithmetic is:

110 × (700 − 120) = 63,800 ms ≈ 1 minute 4 seconds removed

That is roughly a 9% reduction, and it usually feels like considerably more than 9% because the pauses being removed are exactly the moments where attention drifts. Longer dead air — a 20-second wait while a build compiles — is where the tool earns its keep, because a single such gap is worth twenty ordinary pauses.

Practical tip: run the detection once with the defaults, use Preview With Cuts Applied, and only then start moving sliders. Judging a threshold number in the abstract is nearly impossible; judging whether a 20-second preview sounds natural takes seconds.

Filler Words: What Is and Is Not Possible in a Browser

Removing "um", "uh", "like" and "you know" is a different problem from removing silence. Silence is a signal-level property you can measure directly. A filler word is a linguistic category — you have to recognise the word before you can decide to delete it, which requires speech recognition, and you have to know where its boundaries fall to the millisecond, which requires forced alignment.

In practice, most filler words are surrounded by pauses, so silence trimming already tightens them considerably. Where a filler is welded onto the following word ("um-so-anyway"), no threshold will separate them cleanly, and the honest answer is that this is a manual edit. The review list exists precisely for these cases: you can disable a cut the tool proposed, or leave a region alone and handle it in a full editor afterwards.

Why Manual Review Is Not Optional

Every automatic trimmer produces a small number of wrong cuts, and the failure modes are predictable. Plosive consonants (p, t, k) begin with a brief closure that is genuinely silent — trim into it and the word loses its attack. Trailing fricatives (s, f, sh) decay gradually and can drop below threshold before they have finished. Speakers who drop pitch and volume at the end of a sentence often lose their final syllable.

Toggling individual cuts on and off in the review list is faster than it sounds, because errors cluster: they happen at the same speaker's same habits, so once you have spotted one you know what to look for. Scanning the shortest proposed cuts first tends to surface problems quickly, since a wrongly detected "silence" inside a word is almost always a short one.

When You Should Not Remove Pauses

Known Limitations, Stated Plainly

Everything happens in your browser, which sets real ceilings. Decoding audio expands it dramatically in memory — an hour of stereo audio at 48 kHz occupies roughly 690 MB as 32-bit float samples — so very long files can exhaust a tab before processing starts. Files in the 5–20 minute range are comfortable on ordinary hardware; feature-length recordings are not the right job for a browser tool.

For video, the trimmed export is produced through the browser's own recording pipeline, so the container and codec are whatever your browser supports rather than a format you choose. The result is fine for review copies, uploads and internal sharing. If you need a specific codec, bitrate or a frame-accurate master, run the trimmed file through a desktop encoder afterwards. The tool also processes a single file at a time — there is no batch queue — and it edits only in time, never adjusting levels, noise or EQ.

Nothing Is Uploaded

The file you choose is read with the browser's File API and decoded locally. No copy is sent to a server, there is no account, and nothing is retained after you close the tab. You can verify this rather than take it on trust: open your browser's developer tools, switch to the Network tab, and process a file — you will see no outbound request carrying your media. A stricter test is to load the page, disconnect from the internet, and use the tool anyway. It keeps working, because there is nothing on the other end to talk to.

This matters more than it might seem for this particular tool. Raw recordings are the least filtered thing most people produce: unedited takes contain false starts, names, internal details and things said in the belief they would be cut. Keeping that material on your own machine is a meaningfully different privacy posture from uploading it to a processing service.

Frequently Asked Questions

How much time will this actually save on a typical recording?

For unscripted talking-head or screen-recording content, expect roughly 5-12% of total duration from ordinary pauses. Recordings with long dead spots - waiting for loads, builds or page transitions - can drop 20% or more, because a single 20-second gap is worth many ordinary pauses.

Why did it cut the beginning of a word?

Plosive consonants like p, t and k start with a brief silent closure, and some speakers drop volume at the end of a sentence. If the loudness in that window falls below your threshold it is treated as silence. Lower the silence sensitivity, raise the minimum gap to keep, or simply toggle that individual cut off in the review list.

Why is it not detecting obvious pauses?

The pause is probably not quiet in signal terms. Air conditioning, fan noise, traffic or a live music bed raises the noise floor above your threshold. Raise the sensitivity so more of the range counts as silence, or record in a quieter environment.

Can it remove 'um' and 'uh' reliably?

Not on its own. Identifying a spoken word requires speech recognition plus millisecond-accurate alignment, which is a different problem from measuring loudness. In practice most fillers sit between pauses and get tightened anyway; ones fused to the next word need a manual edit.

What is a sensible starting point for the sliders?

Leave the defaults - 400 ms minimum silence and 120 ms retained gap - run detection, and preview. For a fast-paced social clip try 250 ms minimum and 80 ms retained. For tutorials or anything instructional, go the other way: 600 ms minimum and 200 ms retained keeps the delivery breathable.

How long a file can it handle?

Decoded audio is far larger than the file on disk - about 690 MB in memory for an hour of 48 kHz stereo. Files of 5-20 minutes are comfortable on ordinary hardware. Very long recordings may run the tab out of memory, in which case split the file first.

Does the exported video keep its original quality and format?

The export is produced by the browser's own recording pipeline, so the container and codec are whatever your browser provides rather than a format you pick. It is well suited to review copies and uploads. For a specific codec, bitrate or a frame-accurate master, re-encode the trimmed file in a desktop tool.

Is my recording uploaded to a server?

No. The file is read and decoded entirely in your browser, and nothing is transmitted or stored. You can confirm it by watching the Network tab in developer tools while you process a file, or by disconnecting from the internet after the page loads - the tool still works.