Does trimming an MP3 lose quality?
It depends on how the cut is made, and the difference is not small. Ten trims one way left the audio bit-for-bit identical. Ten trims the other way left an error signal louder than the music.
Free toolAudio TrimmerCut a section out of a track on a real waveform, and copy an MP3 out frame by frame instead of re-encoding it.Open the trimmerThe short answer
Trimming an MP3 loses quality if the tool decodes it and encodes it again, and loses nothing at all if the tool copies the frames. Most tools do the first. A few do the second, and the few are worth finding.
An MP3 is not one continuous stream. It is a queue of self-contained frames, each holding 1152 samples of audio and each starting with a header that says how long it is. A cut can be made by finding the frame boundaries either side of the section you want and copying those bytes into a new file. No decoder runs, no encoder runs, and the audio in the result is the same bytes that were in the original.
The price is that the cut lands on a frame boundary rather than exactly where you put it. At 44.1kHz a frame is 26.122 milliseconds, so the in-point moves by up to that much. That is the entire trade, and for most jobs it is not a trade at all.
Why a second encode costs anything
MP3 is lossy on purpose. The encoder models what your ears will not notice, throws that away, and spends the bits it saved on what is left. Done once, from a clean master, at a sensible bitrate, the result is very hard to tell from the original.
The trouble is that the encoder assumes its input is that clean master. Hand it an MP3 that has already been decoded and it has no idea: it sees a waveform, models it, and throws away another slice, this time including things the first encoder had decided to keep. It also cannot recover anything the first pass discarded, so the second pass is pure cost.
This is why trimming is worse than it sounds. You have not asked for a conversion. You have asked to remove some silence from the end, and a tool that re-encodes charges you a full generation of loss on the entire file for it.
Measured: ten trims, two ways
The claim above is easy to make and rarely shown, so here it is on a signal you can rebuild. Both columns start from the same MP3 and are asked for the same 20 second region, ten times over, each generation working on the last one's output.
Method. The source is 30 seconds of pink noise mixed three-to-one with a 440Hz sine and limited to −1 dBFS, 44.1kHz stereo, generated with ffmpeg's anoisesrc and sine so it can be recreated exactly. That was encoded once with LAME at 192kbps CBR to make generation 0. Generation 1 takes the same 20 second region out of it two ways: by copying frames, and by decoding and re-encoding at the same 192kbps. Every later generation re-saves the whole of the previous one the same way. The difference column is generation N's mono decode subtracted from generation 1's, sample by sample, reported as the RMS of what is left. The reference signal itself sits at −15.60 dBFS. Run on ffmpeg 8.1.2 and LAME, macOS 15.6 on Apple silicon, 24 August 2026.
| Generation | Frame copy: difference | Re-encode: difference | Re-encode: level |
|---|---|---|---|
| 1 | digital silence | digital silence | −15.60 dBFS |
| 2 | digital silence | −28.43 dBFS | −15.83 dBFS |
| 3 | digital silence | −24.15 dBFS | −16.04 dBFS |
| 4 | digital silence | −21.01 dBFS | −16.26 dBFS |
| 5 | digital silence | −19.44 dBFS | −16.47 dBFS |
| 6 | digital silence | −18.27 dBFS | −16.68 dBFS |
| 7 | digital silence | −16.88 dBFS | −16.88 dBFS |
| 8 | digital silence | −16.10 dBFS | −17.09 dBFS |
| 9 | digital silence | −15.22 dBFS | −17.29 dBFS |
| 10 | digital silence | −14.39 dBFS | −17.49 dBFS |
The frame copy column is not rounded down to zero. It is zero. Subtracting generation ten from generation one gave digital silence at every step, and the files themselves never changed: 480,861 bytes and 20.009796 seconds at generation 1 and at generation 10. Checking the bytes directly confirmed it, with all 120,999 audio bytes of a separate test cut matching the source frames exactly.
The re-encode column climbs steadily, and by generation 10 the error sits at −14.39 dBFS against a signal at −15.60. The error is louder than the audio. The last column is the one you would notice first, though: the file gets quieter every time it is saved, dropping 1.89 dB over the ten passes without anyone touching a volume control.
What this number is not. An RMS difference is a poor guide to what you would actually hear. MP3 is a perceptual codec, so it deliberately does not preserve the waveform, and even one honest encode produces a large difference signal that is nearly inaudible. Two generations of a 192kbps file will not sound broken to most people. Ten will. The reason to prefer the copy is not that a single re-encode is a disaster, it is that the copy costs nothing, so there is no reason to pay anything at all.
Measured: where the cut actually lands
The frame boundary is the real limit of lossless cutting, so it is worth knowing how big it is in practice rather than in theory. This asked the same file for 500 in-points spread evenly across it, and recorded how far each cut moved.
Method. The same generation 0 file, 44.1kHz, where one frame is 26.1224 milliseconds. 500 in-points at even intervals across the first 25 seconds, each cut to a four second selection, measuring the distance between the time asked for and the time the cut landed on. 24 August 2026.
| Measure | Result |
|---|---|
| Frame length at 44.1kHz | 26.1224 ms |
| Mean distance moved | 13.07 ms |
| Median | 13.14 ms |
| 95th percentile | 24.73 ms |
| Largest | 26.08 ms |
| Landed exactly | 1 of 500 |
Thirteen milliseconds is shorter than a spoken consonant and far shorter than the gap between two words. For trimming speech, topping and tailing a song, or making a ringtone, it is invisible. It matters for exactly one job, which is cutting a loop that has to land on a beat, and there the answer is to accept a decode and save an uncompressed file.
At 48kHz the frame is 24 milliseconds instead, because a frame is a fixed number of samples rather than a fixed length of time. Half-rate MP3s, the 22.05kHz and 24kHz ones, carry 576 samples a frame instead of 1152, so their quantum is 26.1 and 24 milliseconds too.
Every way to cut an MP3, and what each one costs
| Method | Re-encodes? | Notes |
|---|---|---|
ffmpeg with -c copy | No | ffmpeg -ss 30 -to 60 -i in.mp3 -c copy out.mp3. The reference implementation, free, on every platform. Drop -c copy and it silently re-encodes instead, which is the single easiest mistake to make here. |
| A browser tool that parses frames | No | Same idea, no install, and nothing leaves the machine. This is what the audio trimmer here does. |
| mp3DirectCut | No | Windows only, free, and has done frame-level editing for twenty years. It can also change volume without a re-encode, which almost nothing else manages. |
| mp3splt | No | Command line, macOS and Linux. Built for splitting albums at track boundaries rather than for arbitrary trims, but it does the job. |
| Audacity | Yes | Decodes on import, encodes on export. The right tool if you are also filtering, mixing or repairing. The wrong one for a plain cut. |
| GarageBand, iMovie, Premiere | Yes | All sample editors underneath. Same trade as Audacity, with more of it. |
| Most online cutters | Yes | They decode server-side and encode the result. Several also upload your file to do it. |
What the online cutters actually do with your file
Worth checking before you hand one a recording. On 24 August 2026 the first organic result for "audio trimmer" was audiotrimmer.com, and adding a 705 KB MP3 to it produced an Uploading… progress bar that ran to completion before the waveform appeared. The waveform itself arrives as an image drawn on the server. The site's own page states that uploaded files are stored in a temporary folder and removed within two hours, so this is not a hidden behaviour, just an easily missed one.
That is the honest state of the category. A tool that draws your waveform on a server has your audio on a server, and a tool that hands back a re-encoded file had to decode it there to do so. Neither is necessary: a browser has had a full audio decoder built in for over a decade, and the frame arithmetic is a few hundred lines.
The way to check any of them yourself is to open the network panel before you add the file. An upload is a request with your file's size in it and it is impossible to miss once you are looking.
When re-encoding is the right answer
There are three cases, and outside them the copy wins every time.
You need a fade. A fade multiplies the samples by a curve, and samples only exist after a decode. There is no version of this that keeps the copy. If the only reason you want the fade is to stop a clip ending abruptly, try moving the out-point into a quiet moment first, which often sounds better anyway.
You need the cut on an exact sample. A loop that has to line up to a beat cannot tolerate 13 milliseconds of drift. Decode, cut where you want, and save uncompressed.
The source is much bigger than the job. A 320kbps master becoming a short alert sound is not going to suffer, and the size saving is real. Encode once from the highest quality source you have rather than twice from a copy.
How to do it, on each platform
Any browser, including on a phone. Open the audio trimmer, drop the file in, set the two points and save. It parses the frames and copies them, so an MP3 in gives an MP3 out with nothing decoded, and nothing is uploaded. The badge above the save button says which path the export is taking and why.
Windows. mp3DirectCut is the specialist and it is free. For anything more than a cut, Audacity, accepting the re-encode.
macOS. There is nothing built in that does this losslessly. QuickTime's trim re-encodes and Music will not edit at all. Install ffmpeg through Homebrew and use -c copy, or use the browser.
iPhone and Android. Use the browser. The apps all decode, and a page does not have to.
Anywhere, from the command line.ffmpeg -ss 30 -to 60 -i in.mp3 -c copy out.mp3 keeps the section from thirty to sixty seconds. Put -ss before -i as shown: after it, ffmpeg decodes everything up to the in-point and throws it away, which is slower and, with -c copy, can put the cut in a different place than you expected.
A note on the first frame
One detail separates a cut that is genuinely clean from one that clicks at the start, and most descriptions of frame-level cutting skip it. Layer III lets a frame borrow spare bytes from the two frames before it, a mechanism called the bit reservoir, which is how a quiet passage can lend bits to a loud one.
So the frame at your in-point may need data that is no longer in the file. Start there and the decoder reaches backwards into whatever happens to precede it, and you hear a click. The fix is to walk forward to the first frame that borrows nothing, which costs at most two frames, about 52 milliseconds. A tool that does not do this will produce a file that is technically lossless and audibly wrong on the first note.