Why this is fast
Native server ffmpeg runs roughly 4–8x faster than browser WebAssembly on the same encode, with real SIMD and threading. Uploads land at the nearest Backblaze B2 point of presence via a presigned URL, the encode runs server-side, the smaller MP3 comes back through Bunny CDN from the same edge. Even an hour-long WAV being shrunk by 95% to a 64 kbps MP3 finishes inside the time the upload took.
What this tool does, exactly
We run ffmpeg -i input -vn -c:a libmp3lame -b:a <bitrate> -f mp3 output.mp3 with the bitrate you picked. -b:a sets a constant bitrate (CBR) rather than VBR, which makes the output size predictable to within a percent or two of the quoted bitrate times duration math — useful when you have a hard size ceiling. -vn drops any embedded album art so it does not eat bytes you wanted spent on audio. No sample-rate downconversion, so a 48 kHz source stays 48 kHz.
Bitrate vs quality: speech vs music
The right setting depends entirely on what the file contains. Spoken word — voice memos, interviews, podcasts, screen-recording narration — survives aggressive compression. 64 kbps or 96 kbps is usually indistinguishable for speech because voices occupy a narrow frequency band. Music is the opposite: cymbals, reverb tails, and bass need more headroom, so 128 kbps is a sensible floor and 192 kbps is close to transparent for most listeners. If you are not sure what is in the file, 96 kbps is a safe default that almost always shrinks things meaningfully without an obvious quality hit.
Sister tools
Need MP3 from a non-MP3 file first? MP3 converter and audio converter both handle the format step. Pulling audio out of a video? Video to audio converter. Trim the MP3 before compressing? MP3 cutter. Compressing a video instead of audio? Video compressor. If the goal is sharing rather than emailing, Clipy records and hosts the file on a shareable link — no size limit on the receiving end.