Compress a Video for Discord's Upload Limit

Three tiers, and one warning printed on Discord’s own page that matters more than the numbers.

The free-tier figure is stated as “For non-Nitro subscribers, the maximum file upload is 20MB” in Discord’s File Attachments FAQ, whose body was last edited on 13 August 2026. The paid tiers are listed as “Share larger files up to 500 MB” and “Share larger files up to 50 MB” in What are Nitro & Nitro Basic?.

One more line from that FAQ is worth having, because it saves you a whole class of mistake. Discord lists the video it accepts as “MP4 (Video encoded with H264, HEVC/H265, or AV1)”. H.265 is explicitly on the list, which means you can spend your 20 MB on a more efficient codec rather than on H.264 compatibility you do not need.

A video file is, to a very good approximation, its bitrate multiplied by its duration. So if you know the duration and you know the size you are allowed, the bitrate is fixed:

total kbps = (target MB x 8192) / duration in seconds
video kbps = total kbps - audio kbps

Worked on our test clip, which runs 60.000 seconds with a 128 kbps AAC track. Target 19 MB rather than the full 20, for reasons in a moment:

(19 x 8192) / 60  = 2594.1 kbps total
2594.1 - 128      = 2466 kbps of video

Then hand that number to the encoder in two passes. The first pass measures the clip, the second spends the budget where it helps:

ffmpeg -y -i input.mp4 -c:v libx265 -b:v 2466k -preset medium \
  -x265-params pass=1:stats=x265.log -an -f mp4 /dev/null

ffmpeg -i input.mp4 -c:v libx265 -b:v 2466k -preset medium \
  -x265-params pass=2:stats=x265.log \
  -tag:v hvc1 -c:a aac -b:a 128k output.mp4

We ran that at six different budgets on the same 60-second clip and compared what the arithmetic predicted against what landed on disk:

Every prediction landed inside 2%, and everything above 800 kbps inside 1%. Two-pass bitrate targeting is the only technique on this site that reliably hits a byte count, and this is why: the encoder is given a budget rather than a quality goal, so it spends exactly what it was told to.

VMAF is a perceptual quality score from Netflix where 100 means identical to the source. Roughly 90 is where a clip stops looking obviously compressed on a laptop display. Note where 20 MB puts a full minute of 1080p: 90.56. That is fine.

Look at the last row of that table again. We asked for 49 MB of Nitro Basic’s 50 and got 50,244,170 bytes. If Discord counts megabytes as 1,000,000 bytes, that file is over the line. If it counts them as 1,048,576 bytes, it is comfortably under at 47.9. Nobody outside Discord knows which, and the difference is 4.9%.

The 8192 in the formula quietly treats a megabyte as 1,024,000 bytes, which sits between the two definitions. That is fine when you leave headroom and dangerous when you do not.

Leave 5%. It costs you almost nothing in quality and it removes the round trip where the upload bounces and you have to encode again. Container overhead, a stray metadata atom and the encoder’s own rounding all live in that margin.

Yes, and it is the clearest demonstration of what a modern codec is for. Here the file size is fixed by the cap, so the only thing that can change is how good the picture is inside it. Same clip, same two-pass budgets, both codecs at -preset medium:

The gap grows as the budget tightens. At a comfortable 6562 kbps the two codecs are within a third of a VMAF point and the choice does not matter. At 400 kbps, which is what a five-minute clip gets inside 18 MB, H.265 is eight points ahead. Discord is exactly the squeeze where the newer codec earns its keep, and Discord accepts it.

Two practical notes. Add -tag:v hvc1 or Finder, QuickTime and Photos will refuse to preview the H.265 file even though it is valid. And if the clip is going to a server where someone might be on a very old Android phone, H.264 is still the safer choice. The full argument, with measurements across four kinds of source material, is in H.265 vs H.264: what actually changes.

Because CRF is a quality target and Discord gives you a size target. Those are different instructions and only one of them is answerable in advance.

Set CRF 26 and the encoder produces whatever number of bytes that quality costs on your particular footage. On a static talking head that might be 4 MB a minute. On a handheld shot of moving water it might be 40. The setting is identical, the outcome is not, and you find out only after the encode. That is fine when you want a consistent look across a library and useless when a server is going to reject the file at 20,971,521 bytes.

So: CRF when you care how it looks, two-pass bitrate when you care how big it is. There is more on what CRF actually controls in reducing video file size without losing quality.

One thing to do before either: cut the dead footage. A stream copy removes it at zero quality cost, and on a screen recording it is usually the single biggest saving available.

ffmpeg -ss 4 -t 45 -i input.mov -c copy trimmed.mp4

Every second you delete gives every remaining second a larger share of the 20 MB. A 45-second clip at the same visual quality as a 60-second one is 25% smaller for free.

Then pick a quality level, encode, and check. It is a worse method and it is what most people will actually do, so here is how to make it work: start at H.265 CRF 28, look at the file size, and move the number by two in whichever direction you need. Each step of two changes the size by roughly a quarter.

Smol does that route with a queue and a preset list rather than a text field. Its default is H.265 in an MP4, the quality ladder runs from maximum at CRF 18 down to tiny at CRF 34, and if you want the number yourself the range is CRF 0 to 63 across all nine x265 encoder presets. It is a one-time $29 purchase for one Mac, it works on a folder at a time, and nothing leaves the machine. What it will not do is hit 20 MB exactly, because nothing driven by CRF can.

If you are sending clips to Discord often enough for this to be a workflow rather than a chore, the thing to automate is the trimming and the encode together, which is covered in batch compressing videos on Mac.

When you need an exact size, which is the entire point of this page. Two-pass bitrate targeting is the correct tool and ffmpeg does it free, in two lines, with the arithmetic above. HandBrake does it through a GUI: set Video to Avg Bitrate, tick 2-Pass Encoding, and it will hit the number. HandBrake is free, GPL, actively developed, and better at this specific job than we are.

When it is one clip and you have Nitro. 500 MB is more than an unedited ten-minute screen recording needs. Drag it in.

When the real answer is a link. If the clip is long, post it somewhere with a URL and paste that. Discord renders the embed, nobody waits on a 20 MB download, and you skip the compression entirely.

Where we do earn it: a folder of clips rather than one, mixed with images and PDFs, and a default that is already H.265 rather than a settings tab you have to relearn. The same trade-off for four different tools is measured in how to compress a video on Mac, and the screen-recording case specifically in compressing a Mac screen recording.