Compress an audio file
Get a recording under a size limit that is refusing it.
How it works
Audio size is not a quality setting with a slider hidden behind it. It is arithmetic: bitrate multiplied by duration, plus a few kilobytes of header. A file at 320 kbps occupies 2.4 MB per minute and the same recording at 96 kbps occupies 0.72 MB per minute, every time, on any material. That predictability is useful, because it means you can work backwards from the limit you have been given.
Divide the ceiling in megabytes by the length in minutes, multiply by 133, and you have the bitrate in kbps that fits. A 25 MB email attachment limit and a 47-minute recording gives about 71 kbps, so 64 kbps clears it with room to spare.
Three levers, in the order worth pulling them
Channels come first, and not for the reason people expect. Switching a stereo file to mono does not shrink it: the bitrate sets the size, so 96 kbps mono and 96 kbps stereo come to the same bytes — measured, 6.1 seconds at 96 kbps gave 74,135 either way. What mono buys is every bit spent on one channel instead of split across two, so a mono recording holds up at half the bitrate stereo needs. A voice memo, a lecture capture or a single-microphone interview stores the same signal twice, and the saving arrives once you drop the bitrate to match.
Bitrate is next and is the lever with a real trade. Speech survives compression far better than music does, because a voice occupies a narrow frequency range and has long stretches the encoder can predict. Music at 96 kbps starts to sound thin and glassy on cymbals and strings; speech at 96 kbps is hard to distinguish from the original, and remains clear at 64 kbps and even 48 kbps.
Sample rate is the last resort and the bluntest. Halving it removes the top half of the frequency range outright. That is destructive for music and reasonable for voice, where 22.05 kHz keeps every consonant a listener needs and 16 kHz is what telephone systems and speech recognition have always used.
Recompression compounds
This page decodes the file and encodes it again, so an MP3 processed here goes through a second round of lossy compression. Reducing 320 kbps to 192 kbps is close to free in practice. Taking an already-thin 96 kbps file down to 64 kbps is audibly worse than encoding 64 kbps from the original would have been, because the second encoder spends bits describing the first one's artefacts.
Where the original still exists in a lossless form, compressing from that instead gives a better result at the same size. Where it does not, start from the largest copy you have and make one reduction rather than several.
Questions
How small can I get a file without it sounding bad?
It depends entirely on the content. For a single speaker, 64 kbps mono is transparent enough that almost nobody would identify it in a comparison, and cuts a typical podcast episode by three quarters. For music, 128 kbps is the point below which most listeners start to notice something, and 96 kbps is where they notice reliably. Convert once at your best guess and listen before committing.
Is my file uploaded?
No. Decoding and encoding both happen in a Web Worker on your machine, using a WebAssembly build of the LAME encoder that downloads once with the page. Open the Network tab and run a conversion: no request carries your audio, because there is no server here to receive one.
Why did the size barely change?
Almost certainly because the source is already at or below the bitrate you asked for. Encoding a 96 kbps file at 128 kbps makes it larger while sounding slightly worse, which is the one outcome to avoid. Check the source bitrate in your file manager or player first, and pick a target below it.
What can I feed it?
MP3, M4A, AAC, WAV, FLAC, OGG and the audio inside an MP4 or MOV. The output is always MP3, because the question this page answers is about size and compatibility at once, and MP3 is the format with no compatibility question attached. For a lossless result at a smaller size, convert to FLAC instead.