Source—
Kept—
Output—
Re-encoded—
Two things go wrong with an online audio cut, and neither is visible until you play the result. The first is that the cut lands mid-word, which is the single most recognisable mark of an edit made in a hurry — a waveform four hundred pixels wide cannot show you a syllable. The second is that the clip you kept was decoded and re-encoded on the way out, so a lossy file has been through a second lossy pass for no reason at all. This cutter fixes both: it finds the nearest genuine silence to each handle and offers to move the cut there, and it copies the compressed audio through untouched wherever the format allows — then reads the codec back off the finished file to prove it did.
Step by step
01Open the file
Audio, or a video you want the audio out of. It is decoded by the browser's own codecs in this tab, and the waveform is drawn from the decoded samples rather than from a preview.
02Place the handles
Drag them on the waveform, type exact times, or nudge with the arrow keys — a frame at a time, or a second with shift held. Play loops the selection, so you hear the cut rather than the file.
03Snap to silence
One button moves each handle to the nearest quiet moment within a second and a half. If there is no quiet moment near a handle, it says so rather than moving the cut somewhere arbitrary.
04Check what came out, then take it
The ledger says whether the audio was copied or re-encoded, and why. Both are legitimate — the point is knowing which one you got.
A worked cut
The sample this tool opens with: an eight-second phrase of five notes with real silence between them, generated in the browser rather than downloaded. Every figure below is what the tool reports on it.
Given
Four cuts of the same file
0:00 → 0:01 1.0 s 6.2 KB copied
0:00 → 0:02 2.0 s 13 KB copied
0:00 → 0:04 4.0 s 29 KB copied
0:02 → 0:04 2.0 s 31 KB copied ← same length, 2.4× the bytes
with a 0.2 s fade in: re-encoded
as WAV: 4.0 s 375 KB re-encoded (13× the Ogg)The two-second cut from the middle of the file is two and a half times the size of the two-second cut from the start, because compressed audio is variable-bitrate: it spends bits where there is sound and almost none where there is not, and the opening two seconds are mostly silence. This is why a duration cannot predict a file size, and why a cutter that quotes one before doing the work is guessing. It is also the clearest possible demonstration that nothing is being re-encoded — a re-encode at a fixed bitrate would have produced two files of near-identical size. The fade row is the trade in the other direction: a fade rewrites the samples, so the copy is forfeited, and the tool says so at the moment you move the slider rather than afterwards.
Before you cut
A cut in the middle of a word is the giveaway
Speech is continuous and a waveform on screen is a few hundred pixels wide, so a handle placed by eye lands wherever it lands — and a clip that starts halfway through a syllable sounds wrong immediately even to someone who could not say why. Finding the gap is the part a machine should do.
Silence is measured against the recording, not an absolute
−40 dBFS is silence in a studio and ordinary room tone in a phone video, so a fixed threshold finds nothing on real material. The threshold here is a twentieth of the track's own loudest moment, and it is measured on the energy of each slice rather than its peak — a single stray sample in an otherwise quiet gap moves the peak to the top and leaves the energy where it was.
Trimming does not require re-encoding
A compressed audio file is a sequence of independently decodable frames, so a cut can be made by copying the frames inside the selection into a new container. Nothing is decoded, nothing is quantised again, and the clip is bit-identical to that span of the original. Upload-based cutters re-encode because a pipeline that always re-encodes is simpler to build.
Every lossy re-encode costs something
MP3 and AAC discard detail deliberately, and a second pass discards more — including artefacts introduced by the first, which it now has to spend bits describing. It is not catastrophic, and it is entirely avoidable for an operation that is really just choosing where to start reading.
A fade is a different operation
Changing the volume over time means changing the samples, which means decoding, applying the envelope, and encoding again. That is the correct behaviour and it costs the lossless copy — worth it for a ring tone or a podcast intro, not worth it for pulling one track out of an archive.
No browser can encode MP3
Browsers ship an MP3 decoder and essentially never an MP3 encoder, so a browser-based tool cannot convert anything into MP3. It can cut an MP3 perfectly, because that is a copy rather than an encode. Asking for MP3 output from a non-MP3 source is refused here with that explanation rather than a generic error.
The judgement call
What you are going to do with the clip decides it.
Trimming an MP3 you want to keep as an MP3
Same as source
The frames are copied into a new MP3 file, so the clip is bit-identical to that part of the original and nothing is re-encoded.
Audio pulled from a phone video
Same as source
It is almost certainly AAC, which goes straight into an M4A container as a copy. Converting it to MP3 would be a needless second lossy pass — and is not possible in a browser anyway.
A clip going into an audio editor
WAV
Uncompressed, so nothing further is lost and no decoder is needed. Large — four seconds of the sample here is 375 KB against 29 KB as Ogg.
Something to put on a web page
OGG
Opus is the smallest of these at a given quality and is read by every current browser.
You need MP3 specifically and the source is not MP3
Not possible here
There is no MP3 encoder in any mainstream browser. A desktop tool is the honest answer, and the tool says so rather than failing obscurely.
Reference
FAQ
Use a cutter that copies the compressed frames rather than decoding them. An MP3 is a sequence of independently decodable frames, so the ones inside your selection can be written into a new file untouched — the clip is then bit-identical to that span of the original. The Tinapps MP3 cutter does this whenever the output format can carry the input's codec and no fade is applied, and it reads the codec back off the finished file to confirm it happened.
Snap it to the nearest silence. The Tinapps MP3 cutter measures the energy of the whole recording while drawing the waveform and moves each handle to the closest quiet moment within a second and a half — and tells you when there is no quiet moment nearby, rather than moving the cut to the least loud point of a continuous passage.
Not if the tool copies the frames. It does if the tool decodes and re-encodes, which most upload-based cutters do because a pipeline that always re-encodes is simpler to build — a lossy file that has been through a second lossy pass has lost detail for no reason. Applying a fade forces a re-encode in any tool, because a fade changes the samples themselves.
Yes. The Tinapps MP3 cutter decodes and re-writes the file with your browser's own codecs through WebCodecs, so nothing is sent anywhere, there is no upload wait, and there is no file size cap — the practical limit is your machine's memory.
Because browsers ship an MP3 decoder and essentially never an MP3 encoder, so the WebCodecs configuration is simply refused. Cutting an existing MP3 works fine, because that copies frames rather than encoding them. For converting other audio, M4A, OGG, and WAV are all available.
Because compressed audio is variable-bitrate: it spends bits where there is sound and almost none where there is silence. On the sample in the Tinapps MP3 cutter, two seconds taken from the middle is 31 KB while two seconds from the mostly-silent opening is 13 KB. It is also proof that nothing was re-encoded, since a fixed-bitrate re-encode would have produced two files of near-identical size.
Yes — drop the video in and the Tinapps MP3 cutter reads its audio track, draws the waveform, and writes only the audio. The video track is discarded rather than re-encoded, so the operation is as fast as it would be on an audio file.
Not in the Tinapps MP3 cutter. Free upload-based cutters cap the length or the file size to bound their server costs; there is no server here, so the only limit is how much memory the browser tab can allocate for decoding.
The audio is decoded, cut, and re-written entirely in your browser through WebCodecs. Nothing is uploaded, and the clip exists only as the file you download.
Keep going
Video and audio tools
The rest of the category, all running on the browser's own codecs.
Image compressor
The same measure-then-decide approach applied to pictures.
Split PDF
Cutting a document, with the same honesty about what it costs.
MIME types
What audio/mpeg, audio/mp4 and audio/ogg actually mean.