Audio is the part of a video file nobody thinks about, and for most of a compression job that is the correct amount of attention to give it. A 200 MB clip with 2 MB of AAC in it does not have an audio problem.
But audio has a property that video does not: its cost per minute is fixed. It does not care about resolution, it does not care about motion, and it does not fall when you compress the picture. So as you squeeze the video, audio’s share of the file grows, and at the tight end it stops being a rounding error and starts being the reason your clip looks bad.
What audio actually costs
Bitrate times duration, the same arithmetic as everything else. A stereo AAC track at 128 kbps is 0.92 MiB per minute, which comes out at 55 MiB an hour. That is worth carrying around as a reference point because most of the other numbers are multiples of it.
| Format | Typical bitrate | Per minute | Per 10 minutes | Per hour |
|---|---|---|---|---|
| PCM / LPCM, 48 kHz 16-bit stereo | 1,536 kbps | 11.0 MiB | 110 MiB | 659 MiB |
| AC-3 5.1 | 384–640 kbps | 2.7–4.6 MiB | 27–46 MiB | 165–275 MiB |
| AAC stereo, high | 256 kbps | 1.8 MiB | 18 MiB | 110 MiB |
| AAC stereo, default | 128 kbps | 0.92 MiB | 9.2 MiB | 55 MiB |
| AAC stereo, lean | 96 kbps | 0.69 MiB | 6.9 MiB | 41 MiB |
| AAC mono, speech | 64 kbps | 0.46 MiB | 4.6 MiB | 27 MiB |
| Opus stereo | 48 kbps | 0.34 MiB | 3.4 MiB | 21 MiB |
| Opus mono, speech | 32 kbps | 0.23 MiB | 2.3 MiB | 14 MiB |
The top row is the one that produces surprises. Uncompressed PCM is what screen recorders, camcorders, older AVI files and some professional cameras write, and at 11 MiB a minute an hour of it is two thirds of a gigabyte of audio in a file you assumed was all video. If a recording seems inexplicably large for its picture quality, check the audio stream before you touch anything else.
When audio stops being negligible
Take a five-minute clip and a 10 MB ceiling. Ten mebibytes across 300 seconds is 280 kbps for everything. Keep a 128 kbps stereo track and you have handed 46% of the entire file to audio, leaving about 140 kbps for the picture, which is under the threshold where H.264 can hold a coherent image together at any resolution. You would get a small file with a broken picture and pristine sound, which is not a trade anyone wants.
This is why target-size mode on this site scales the audio allowance to the budget rather than using a fixed number. Below about 400 kbps total it drops audio to 64 kbps, between 400 and 900 it uses 96, and above that it uses 128. On that same five-minute clip in 10 MB, the 64 kbps allowance leaves 204 kbps for the video, which is a workable 360p rather than an unworkable anything. You can see the same arithmetic laid out per clip length on the 10 MB page and its neighbours on the size-target hub.
The general shape of it: audio matters in inverse proportion to how much room you have. At a 100 MB ceiling on a one-minute clip, the audio track is under 1% of the file and you should ignore it entirely. At an 8 MB ceiling on a five-minute clip, it is the difference between a video and a slideshow. The 8 MB page is where this bites hardest.
Stripping audio is free, and it is instant
If the video does not need sound, removing it costs nothing at all, because you can drop the audio stream without re-encoding a single frame of picture:
ffmpeg -i input.mp4 -c:v copy -an output.mp4
-c:v copy passes the video through untouched and -an discards the audio. This runs at disk speed, produces no quality loss whatsoever, and on a ten-minute clip with a 128 kbps track it removes 9.2 MiB. If your file is 11 MB and the limit is 10, that command is the entire solution and you never needed a compressor.
The cases where this is the right call are more common than people expect. Timelapses, b-roll, silent screen captures, anything replacing an animated GIF, anything going into a page that autoplays it muted, and the very large category of clips whose audio track is thirty seconds of room tone and a keyboard.
The cases where it is wrong are worth naming too. A video that plainly should have sound and has none reads as a broken file rather than a deliberate choice, and viewers will assume something failed. If there is any dialogue at all, keep it and cut the bitrate instead.
Mono is usually the honest choice for speech
A great deal of video audio is one person talking into one microphone, recorded as a two-channel file where both channels carry the identical signal. That is a dual-mono track, and encoding it as stereo spends bits describing two copies of the same thing.
Modern AAC and Opus encoders use joint stereo and will not waste the full double, but they will not get you all the way down either. Telling the encoder outright is better:
ffmpeg -i input.mp4 -c:v copy -c:a aac -b:a 64k -ac 1 output.mp4
-ac 1 downmixes to a single channel. Again the video is copied, so this finishes almost immediately. For a single voice, 64 kbps of mono AAC is genuinely fine, and 96 kbps mono is comfortable. The people who will notice are the ones listening to music, and music is the case where you should not be doing this.
Note the difference between mono and stereo here rather than the raw bitrates. A 64 kbps stereo track and a 64 kbps mono track are the same file size, but the mono one sounds considerably better, because all of the bits went to one channel instead of being split.
Copy or re-encode?
Re-encoding a lossy audio track into another lossy format is generation loss. AAC at 128 to AAC at 128 comes out slightly worse than it went in, for no size benefit at all. If the track is already efficient and already compatible, copy it with -c:a copy and leave it alone.
Two things override that. The first is compatibility, since an AC-3 or DTS track has to be converted to reach a phone or a browser regardless of what it costs. The second is size arithmetic: if you are aiming at a hard byte ceiling, a copied track has an unknown bitrate, and you cannot subtract an unknown from a budget. That is why target-size mode here always re-encodes the audio even when copying would be cleaner. It is a deliberate trade of a little audio quality for the ability to actually hit the number.
To find out what you have before deciding:
ffprobe -v error -select_streams a -show_entries stream=codec_name,channels,sample_rate,bit_rate \
-of default=noprint_wrappers=1 input.mp4
AAC or Opus
Opus is the better codec by a clear margin at low bitrates, and it is not close for speech. Opus at 48 kbps stereo holds up against AAC at something closer to 96, and 32 kbps mono Opus is still perfectly intelligible for a voiceover. If you are aiming at a tight ceiling and the audio is a person talking, Opus is a real saving rather than a marginal one.
The catch is where it can live. Opus belongs in WebM and MKV; support for Opus inside MP4 exists on paper and is patchy enough in practice that it is a bad thing to rely on for a file you are sending to someone. So the choice is really a container choice. This tool writes AAC into MP4, MKV and MOV, and Opus into WebM, which follows the same rule for the same reason. The formats reference covers which container to pick, and the WebM page covers the case where WebM is the right destination.
The order to do things in
Look at the audio stream first, because it takes one command and occasionally ends the job. Uncompressed PCM in a file you thought was video-heavy is not rare, and neither is a 5.1 track in a rip that only ever gets played on a laptop.
Then decide whether you need sound at all, since if you do not, the strip is free and lossless and you can stop. If you do, drop to mono at 64 to 96 kbps for speech, and only keep 128 or higher for music or anything where the audio is the point.
After that, forget about it and go and work on the video, which is where the remaining 90% of the file is. The bitrate explainer and the guide to cutting size without visible loss are the next things to read.