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 because the saving is the largest and the cost is often zero. A recording made with one microphone into a stereo file holds the same signal twice. Mono halves the size and removes nothing that was there. This applies to most voice memos, lecture captures, phone recordings and single-source interviews.
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.