Fit an audio file under Discord's limit

How the planner works

Why a bitrate, not a magic button

Audio file size is almost purely bitrate × duration, which leaves exactly two levers. Bitrate is the first, and it is the one smallcord pulls for you: to land a clip under a hard cap it picks the highest constant bitrate where bitrate × seconds ≈ target bytes, holding back ~3% for the container's own overhead — MP3 frame headers, an ID3 tag, or the Ogg pages an Opus stream is wrapped in. That's the same math the planner in this repo is unit-tested against, so the number you see is the number the tests lock.

Duration is the second lever, and it is yours alone. Shortening someone's recording is destructive, so nothing is ever cut for you: the Start / End boxes in the in-browser compressor above start empty and stay empty until you type a range, and leaving them blank compresses the whole file exactly as before. Where the bitrate lever runs out — a 60-minute voice memo under the free 10 MB tier would need ~22 kbps, below the honest floor — the tool now offers the range that does fit (the first 42:22 at 32 kbps) as a one-click prefill you still have to confirm. Two scopes, kept separate on purpose: those boxes trim the in-browser compressor only, by slicing the decoded audio before it reaches the encoder; the ffmpeg commands below trim on your machine, where -t tells ffmpeg how many seconds of the input to encode, and they still handle inputs (and output formats) the browser can't.

MP3 or Opus? At or below ~96 kbps the planner recommends Opus: at low bitrates it sounds dramatically cleaner than MP3, and Discord plays it inline. Above that it recommends a plain MP3, which every device and app understands. There's an honest floor at 32 kbps — below that even Opus turns music to mush — so if fitting a very long recording under a small tier would need less than 32 kbps, the planner says so plainly and suggests a bigger tier or splitting the file, instead of handing you a bitrate that makes an unusable file.

What about AAC / .m4a? Flip the output-format switch above to AAC and smallcord keeps the exact same fitted bitrate but writes an .m4a file instead. AAC is the codec Apple's apps default to, so an .m4a drops straight into iMovie, Voice Memos or an iPhone without a conversion step, and Discord still plays it inline. The command it hands you uses ffmpeg's built-in aac encoder — chosen deliberately because it ships in every ffmpeg build. The alternative libfdk_aac encoder sounds a little cleaner at the same bitrate, but it's left out of most prebuilt ffmpeg binaries for licensing reasons, so a command that assumed it would simply fail for many people. At the bitrates that fit a Discord cap the built-in encoder is perfectly fine; if ffmpeg -encoders shows you have libfdk, swapping in -c:a libfdk_aac is an easy upgrade.

Honest limits: this is a planning estimate, not a byte-exact promise. A real encoder hits a target average bitrate with tolerance, and variable-bitrate content wanders a little. The estimate is deliberately conservative (it already adds the ~3% overhead back), so a first pass should land under your limit; if it ever lands slightly over, drop the bitrate about 5% and re-encode.

Got a different kind of file? Fit a video (MP4/MOV/WebM) plans a target bitrate the same way, fit a GIF converts it to a tiny inline MP4, and fit an image re-encodes a PNG or JPEG fully in your browser — all to slip under the same Discord caps.