Free Audio Trimmer

How It Works

1. Load an audio file. Drop or select an MP3, WAV, OGG, AAC, FLAC or M4A file. The browser decodes it locally to draw the waveform; nothing is uploaded.
2. Set start and end points. Drag the handles directly on the waveform or type precise timestamps to the millisecond. The selection highlights the kept region.
3. Preview the source while you adjust. The audio player plays the original file with a playhead overlaid on the waveform, useful for finding the exact split point by ear.
4. Choose output format and trim. MP3 (LAME VBR ~190 kbps), WAV (16-bit PCM, lossless) or OGG Vorbis (~160 kbps VBR). The trim runs through ffmpeg.wasm in your browser; the trimmed file downloads when ready.

A Short History of the Web Audio API

The Web Audio API is the W3C-standardised JavaScript interface for processing and synthesising audio in web browsers, the foundational technology that lets a webpage decode an MP3 in memory, draw a waveform, route audio through filters or play synthesised tones with no plugins. The first prototype was built by Chris Rogers at Apple inside the WebKit project in 2010. The W3C Audio Working Group published its First Public Working Draft on 14 December 2011; after almost a decade of revisions and browser implementation cycles, the W3C published the Web Audio API as a W3C Recommendation on 17 June 2021. The Recommendation document explicitly thanks Chris Rogers as the "former specification editor and original author of this specification." Three classes do most of the work in any browser-side audio tool: AudioContext (the top-level container), AudioBuffer (an in-memory chunk of decoded PCM audio with channel data exposed as Float32Array) and AudioBufferSourceNode (a one-shot playback node). The full graph model supports many more node types (gain, filter, panner, analyser, convolver, delay) and can build everything from a guitar tuner to a synthesiser. This trimmer uses only the decode portion (AudioContext.decodeAudioData()) for waveform visualisation; the actual cut runs through ffmpeg.wasm.

A Tour of the Audio Formats It Reads

WAV (1991, Microsoft + IBM) is the Waveform Audio File Format, a RIFF container holding uncompressed linear PCM samples. CD-quality WAV is 44,100 samples × 2 channels × 16 bits per second ≈ 10.1 MB per minute, which is why a four-minute song in WAV is around 40 MB. WAV's 32-bit data-chunk size header caps a single file at 4 GB; longer recordings need RF64 or W64 extensions. WAV is the universal interchange format precisely because it is uncompressed, simple to parse and patent-free. MP3 (ISO/IEC 11172-3, 1993) is the colloquial name for MPEG-1 Audio Layer III, developed at the Fraunhofer Institute in Erlangen, Germany, with key contributions from Karlheinz Brandenburg, Heinz Gerhäuser, Bernhard Grill, Jürgen Herre and Harald Popp. MP3 was for two decades patent-encumbered; the last of those patents expired on 16 April 2017 in the United States, and Fraunhofer formally announced the termination of its MP3 licensing programme on 23 April 2017. That patent expiry is why free, royalty-free MP3 encoders (libmp3lame, lamejs) became uncontroversially shippable in browser-side tools.

AAC (ISO/IEC 13818-7, 1997) and M4A: AAC was designed as the successor to MP3, with better quality at the same bitrate. M4A is not a separate codec, it is an MPEG-4 Part 14 file (.mp4) carrying audio only. Apple popularised the .m4a extension when it launched the iTunes Music Store on 28 April 2003, using AAC at 128 kbps as the default purchase format. OGG Vorbis (Xiph.Org, 2000-2002) is a free, open, patent-unencumbered lossy codec, Xiph's response to the patent climate around MP3 in the late 1990s. The reference encoder, libvorbis, reached version 1.0 in July 2002. Wikipedia, Spotify (initially), countless games and Linux distributions ship Vorbis. FLAC (Free Lossless Audio Codec, Xiph.Org, 20 July 2001) compresses losslessly, the decoded output is bit-for-bit identical to the input. Typical compression is 50-60% of the source WAV size. FLAC is the de facto archival format for lossless music distribution (Bandcamp, Qobuz, HDtracks, the Internet Archive). Opus (IETF RFC 6716, September 2012) is the most modern royalty-free codec, designed jointly by Xiph.Org, Mozilla and Skype/Microsoft; it fuses Skype's SILK speech codec with Xiph's CELT music codec into one variable codec excellent across the full range from 6 kbps speech to 510 kbps stereo music. Opus is mandatory-to-implement in WebRTC.

How Browser Audio Decoding Actually Works

When you drop a 4 MB MP3 onto the trimmer page, this sequence runs entirely in your browser. FileReader.readAsArrayBuffer(file) reads the bytes from local disk into a JavaScript ArrayBuffer; this is a local read, no upload. The page creates an AudioContext (with a fallback for older WebKit prefixes). audioCtx.decodeAudioData(arrayBuffer) runs the browser's native audio decoder asynchronously (typically the system codec) and hands back an AudioBuffer. The AudioBuffer exposes getChannelData(0) returning a Float32Array of the left-channel samples normalised to −1.0 to +1.0. For a 4-minute mono 44.1 kHz source that's about 10.6 million floats, 42 MB of memory. The waveform-drawing routine downsamples that array into one peak per pixel column on the canvas. The AudioContext is then closed; nothing else holds a reference to the buffer, so memory is reclaimed. For the actual trim, ffmpeg.wasm operates on the original encoded bytes in its virtual filesystem, the Web Audio decode is purely for the picture. What formats decodeAudioData accepts is up to the host browser, not the spec. Practically in 2026: MP3 and WAV are universally decoded; OGG Vorbis works in Chrome, Firefox and recent Safari; AAC/M4A in Safari, Chrome, Edge and modern Firefox; FLAC in all major browsers since approximately 2017; Opus in all modern browsers.

Waveform Rendering, The Peak-Per-Pixel Technique

Drawing a waveform is conceptually simple but easy to do badly. The standard technique, used here, is the min/max envelope: pick a target width in pixels (the canvas's width); compute the step size as samples.length / width; for each output pixel column scan its step samples and find the local minimum and maximum; draw a single vertical line from the min sample to the max sample. The result is the familiar mirrored "envelope" look you see in every modern DAW. Why min/max envelope rather than RMS or single-sample? A naive "for each pixel, plot one sample" approach loses transient detail, a quiet sample might land at a pixel that was meant to represent a loud transient, producing a misleading flat-looking waveform. RMS (root-mean-square) gives a perceptually-accurate loudness curve but loses peak information. The min/max envelope is the visual compromise that has dominated DAW UI since at least Pro Tools and remains the convention in wavesurfer.js, peaks.js (BBC R&D, designed for journalists annotating long-form audio) and Audacity. The implementation here uses devicePixelRatio for high-DPI scaling so the waveform stays crisp on Retina displays. One honest limitation: getChannelData(0) returns the first channel only, so stereo files render the left channel, the trim itself, run through ffmpeg, preserves all channels.

Sample-Accurate Trimming Math

A trim is conceptually simple: produce a new file containing only the samples between time t_start and time t_end of the source. There are two paths. The sample-level approach converts times to sample indices (start_frame = round(t_start × sampleRate)), allocates a new AudioBuffer of length end_frame − start_frame, copies samples per channel, then re-encodes, this is what you would do with pure Web Audio API. The container-level cut (what this tool does via FFmpeg) passes -ss start -to end to FFmpeg and lets it stream the encoded bitstream out, re-encoding through the chosen output codec. The FFmpeg-driven cut is more robust because the encoder handles framing, headers and metadata; the Web-Audio-only path requires writing your own MP3 or Vorbis encoder for output, which is much fiddlier. Sample rate matters: 44.1 kHz is the Compact Disc standard and the dominant rate for music, chosen to be above the Nyquist limit for human hearing (~20 kHz × 2 = 40 kHz minimum) and compatible with the PAL/NTSC video tape decks used to master early CDs. 48 kHz is standard for film, TV and digital video. 16 kHz is the de facto speech-recognition / VoIP rate; 8 kHz is classic landline telephony. 96 kHz and 192 kHz are high-resolution audio rates. This tool inherits the input's sample rate via FFmpeg by default, preserving fidelity unless you explicitly need otherwise. The UI accepts times to one decimal of a second (0:03.5); FFmpeg internally is sample-accurate, so 0.1-second granularity translates to ~4,410 samples at 44.1 kHz, well within human-perceptible accuracy.

Why ffmpeg.wasm and Not lamejs

The biggest historical headache in browser-side audio editing was encoding MP3. Decoding is free, the browser does it. Encoding requires a JavaScript or WebAssembly MP3 encoder. Two options dominate. lamejs is a pure-JavaScript port of the venerable LAME MP3 encoder (originally by Andreas Krennmair / zhuker on GitHub, by mechanically transpiling LAME's C source into JS). The advantage is small footprint (~150 KB minified) and zero dependencies, drop a script tag in and you can encode MP3 in maybe 50 lines of code. The disadvantages are that it only does MP3, the API is fiddly, and performance on long files is mediocre because it is interpreted JS rather than compiled WebAssembly. ffmpeg.wasm is a WebAssembly build of FFmpeg, the universal Swiss-army knife of audio/video processing. The advantage is universality, every codec FFmpeg supports (MP3, WAV, OGG, AAC, FLAC, Opus, dozens of obscure formats), every container, every transformation. The disadvantage is size, the WebAssembly bundle is several MB, much larger than lamejs alone. This tool uses ffmpeg.wasm because it gives you three real output codecs (MP3 via libmp3lame, WAV via pcm_s16le, OGG via libvorbis) from a single shared engine, with the same trim mechanics applied to all of them; lamejs would have constrained the output to MP3 only. The trade-off is the bundle size cost on the first visit.

Common Use Cases

• Ringtone creation. iPhone ringtones must be under 30 seconds; many Android phones cap at 40-60 seconds. Trimming a song's most recognisable hook is the classic use case, and a privacy-conscious one, because uploading a copyrighted song to a third-party site for trimming is a small but real exposure.
• Podcast clip extraction. Pulling a 30-second highlight from a 90-minute episode for social-media promotion. The waveform makes finding the exact in/out points on a sentence boundary much easier than scrubbing blindly through a player.
• Voice memo trimming. Voice memos almost always have dead air at the start (you press record, then start talking) and the end (you finish talking, then stop). Trimming the silence brings the file size down and the perceived quality up.
• Music sample extraction for video edits. A 6-second loop from a song to use as background under a video clip. Trim, export as WAV (lossless, since you'll be re-encoding in the video), import to your video editor.
• Removing intro jingles. Cleaning up a podcast or YouTube audio rip to remove the channel's standard intro before sending to a transcription service.
• Classroom and presentation prep. Trimming a single sound effect, music clip or speech excerpt for use in a slide deck or interactive lesson.

Honest Scope: What This Tool Doesn't Do

This is a focused single-file trim tool, not a digital audio workstation. Things it does not do, that more elaborate competitors handle: no fade in / fade out (the exported clip starts and ends abruptly at the trim points); no multi-track or mixing (single file in, single trimmed file out); no effects (no EQ, compression, normalisation, noise reduction, reverb); no splitting one file into multiple clips in one pass (to cut three sections you trim three times); no gain or volume change; no playback of only the trimmed region: the audio player plays the whole source file with a playhead animated over the waveform during playback. For multi-track editing, fades, effects and mastering, use Audacity (open-source, released by Dominic Mazzoni and Roger Dannenberg on 28 May 2000 at Carnegie Mellon, still actively developed in 2026), Adobe Audition (commercial) or Reaper (commercial, generous free trial). For one-and-done trimming with no setup, this tool is the right shape. The privacy positioning is genuine: voice recordings are personal data, often containing identifiable speech or background sound from a private space; uploading them to a "free online audio cutter" is a real privacy risk that a browser-only architecture sidesteps entirely.

Privacy: Why This Architecture Matters for Audio

Audio recordings carry more identifying information than most file types. A voice memo contains identifiable speech (voice fingerprints are uniquely identifying). A song may be copyrighted material. A meeting recording may contain confidential business discussion or personal medical detail. Server-side audio editors require uploading the file, which means a copy sits in the server's logs, possibly in a CDN cache, possibly in an analytics pipeline, possibly in a backup. For ordinary commercial music this is harmless. For voice memos, meeting recordings, dictation, podcast outtakes, family-event recordings or anything else you would not want copied onto a stranger's hard drive, it is not. This tool runs the entire pipeline (file selection, decode, waveform render, trim, re-encode, download) locally in your browser. No upload, no API call, no log entry. You can verify by opening DevTools' Network tab while you trim: there are no outbound requests carrying audio data. After the FFmpeg WebAssembly bundle has loaded once, you can take the page offline (airplane mode) and the tool still works, the strongest empirical proof that nothing is being uploaded.

Frequently Asked Questions

What formats can I import and export?

Input: MP3, WAV, OGG (Vorbis), AAC, FLAC, M4A, anything your browser's decodeAudioData can read. Modern browsers cover all of these. Output: MP3 (LAME variable bitrate ~190 kbps, the sweet spot for music), WAV (16-bit linear PCM, lossless), or OGG Vorbis (~160 kbps VBR, transparent quality and patent-free). Both encoding and decoding run through ffmpeg.wasm in your browser, so no server is ever involved.

Is there a file size limit?

There is no server-side limit because no upload happens. The practical ceiling is your device's available memory: the file has to be decoded into a JavaScript Float32Array for the waveform display, which means a 4-minute mono 44.1 kHz source needs about 42 MB of RAM during processing. Files up to about 100 MB work comfortably on a typical laptop; longer files (multi-hour podcasts, full albums) may slow down or fail on lower-end mobile. If a load freezes, try a smaller file or trim in segments.

Does trimming reduce audio quality?

For WAV output: no, WAV is lossless, so the trimmed region is bit-for-bit identical to the source samples between the trim points. For MP3 and OGG output: a small additional generation of lossy quantisation is added because the source is being re-encoded. The encoder settings used here (LAME VBR ~190 kbps for MP3, libvorbis quality 5 ≈ 160 kbps for OGG) are well above the threshold most listeners can perceive. If you plan to re-edit the trimmed clip later, choose WAV; if you want a small file for distribution, MP3 or OGG.

Does it support fade in / fade out?

No, the trim is a hard cut at both ends. For fades, multi-track editing, effects or mastering, use Audacity (open-source, free, cross-platform, released 28 May 2000 at Carnegie Mellon) or Adobe Audition. This tool is the right shape for "I just need a cleanly trimmed clip"; for anything more elaborate, a real DAW is the right tool.

Why does the waveform show only one channel?

The waveform draws the first channel (the left channel in a stereo file) as a single envelope per pixel column. Drawing both channels in different colours would double the screen real estate or require overlapping the waveforms, both of which are noisier than the single-channel display for a quick scrubbing UI. The trim itself preserves all channels (FFmpeg copies them as-is from the source) so a stereo recording stays stereo on output, even if the right-channel-only content (a hard-panned-right detail) doesn't show up in the picture.

Are my audio files uploaded?

No. Every step (file selection, decode, waveform render, trim, re-encode, download) runs locally in your browser via JavaScript and ffmpeg.wasm. No upload, no API call, no log entry. You can verify by opening DevTools' Network tab while you trim. After the ffmpeg.wasm bundle has loaded once, you can take the page offline and the tool still works, the strongest proof that nothing is being uploaded. Safe for voice memos, meeting recordings, medical dictation or any audio you would not want copied onto a stranger's hard drive.

Related Tools