Audio Bitrate Reducer

Every lossy codec discards something on every pass. Turning an MP3 into a smaller MP3 keeps less of the original each time, and the quality loss accumulates in the frequencies you are least likely to notice at first — the top end, and anything quiet underneath. That is why the useful range is narrower than the numbers suggest: for speech, 48 to 96 kbps mono is where nearly all of the saving appears with no audible cost, and above about 128 kbps the extra bits are buying very little.

The trap is re-encoding something that was already efficient. A 64 kbps mono voice note squeezed to 48 kbps saves 25 percent of a file that was small to begin with, and a 320 kbps track squeezed to 256 kbps loses real detail for 20 percent. The result block tells you when the target was not below the source, and when the output grew, so you can tell whether a run was worth it.

These are three independent decisions and they are worth thinking about separately. Channels: mono to stereo is a genuine halving of the audio data and, for one voice in a quiet room, indistinguishable. Stereo to mono is the same trade in reverse and is destructive on music, where the stereo image is the recording. Sample rate: almost nothing above 16 kHz is audible to a human, which is why speech at 22,050 Hz sounds fine and why 8,000 Hz is acceptable over a telephone. Keep 44,100 or 48,000 Hz for anything musical, because cymbals and transients live up there.

The tool snaps your requested bitrate down to a rate the chosen codec actually supports. MP3 in particular only has a handful of sensible rates, and asking for 130 kbps does not produce 130 kbps — it produces the nearest tier the encoder offers, which is a different number from the one you typed. Showing you the real target avoids a small, persistent lie.

WAV and FLAC do not discard anything, which is exactly why they are the wrong choice for making a file smaller. Re-encoding a 128 kbps MP3 to WAV produces a file several times larger that contains the same damaged audio, because the damage was already baked in and a lossless container preserves it faithfully. The result block says so plainly when this happens rather than presenting a large file as a success.

Lossless output makes sense in one direction only: capturing a source that is genuinely lossless to begin with, or archiving a master you intend to edit and re-encode later. For anything downloaded from the web, shrinking it is the only useful direction.

The original size is read from the uploaded file and the output size from the file ffmpeg actually produced, using the same filesystem for both. Nothing is inferred from the bitrate, which is what makes the percentage trustworthy. If the output is larger, the saving is reported as a negative number and the notes explain which combination of format, channels and bitrate caused it — most often a lossless target, or a bitrate that was never below the source.

The bitrate of each file is read with ffprobe, which reports bits per second and is converted to kbps for display. Files that do not declare a bitrate at all — some raw or streamed sources — fall back to size divided by duration, and the result says which of the two you are looking at. The file sizes remain exact in that case; only the rate is inferred.

The re-encode is done with ffmpeg and the metadata with ffprobe, both invoked on the server. That is different from most tools here, and for a good reason: this is the one job that genuinely needs a native binary, and no browser API can re-encode an MP3 to Opus. The consequence is that your file is uploaded, processed, and the result held as a downloadable file rather than being processed on your own machine.

Uploads are capped at 50 MB by default, which is generous for anything recorded as speech. Very long files at high bitrates are the case most likely to hit it — a two-hour stereo recording at 320 kbps is about 280 MB, and reducing its bitrate is exactly the sort of job this tool is for, so raise the limit in configuration if that is your use case.