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.
Upload a file, or record straight from your microphone
MP3, WAV, MP4, WEBM, M4A — processed entirely in your browser
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.
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.
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.
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.
Video input is exported as .webm; audio-only input is exported as .mp3. Both play natively in modern browsers.
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.
| Control | What it does | Raise it when… | Lower it when… |
|---|---|---|---|
| Silence sensitivity | Sets the loudness threshold below which audio counts as silence | The room is noisy and obvious pauses are being kept | Soft consonants, breaths at the start of words, or quiet speakers are being clipped |
| Minimum silence length | How long a quiet stretch must last before it is eligible to be cut (default 400 ms) | The result feels choppy or machine-gun paced | You want tight, fast-cut delivery for social clips |
| Minimum gap to keep | How much silence is left behind after a cut (default 120 ms) | Words are colliding and the speech sounds rushed | You 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.