# Discord

Canonical URL: https://encode.wiki/tools/utilities/discord/
Content version: ca42e61ede0a24f789d7287a0001244ad22f4abf
Status: current
License: CC BY-SA 4.0
Checksum (SHA-256): 3e1a148dc79a319b2fae60bd051e27587efad15b18a502ff1969616ca7c51032

Discord plays uploaded videos inline using each viewer's own app or browser, so a video has to fit the upload limit **and** use a format every recipient's client can decode.

## Upload limits

From Discord's [File Attachments FAQ](https://support.discord.com/hc/en-us/articles/25444343291031-File-Attachments-FAQ):

| Account                   | Limit                      |
| ------------------------- | -------------------------- |
| Free                      | 20 MB (raised from 10 MB in August 2026) |
| Nitro Basic               | 50 MB                      |
| Nitro                     | Up to 1 GB                 |

Boosted servers raise the limit for everyone in them (50 MB at level 2, 100 MB at level 3), and Discord is experimenting with larger limits, so check what your client shows. The limit applies to the file as you select it: the mobile apps now check the size before compressing, as desktop always has.

## Which format to use

Discord's FAQ lists MP4 with H.264, HEVC or AV1 for video.

- **H.264 + AAC in MP4** plays on every client. Use it when you do not know who will watch.
- **AV1** looks much better at the same small size, which matters at 20 MB. Older iPhones and iPads, which only decode AV1 in hardware, may not play it.
- **HEVC** plays only where the viewer's device and browser have HEVC support, which often means hardware decoding; avoid it for general sharing. If you do use it, add `-tag:v hvc1` so Apple devices recognise the stream.

Use 8-bit 4:2:0 (`-pix_fmt yuv420p`) for H.264; browsers and phones generally cannot decode 10-bit or 4:4:4 H.264. Convert HDR sources to SDR first unless you know your viewers have HDR displays (see [Preserve colour and HDR](/guides/preserve-color-and-hdr/)).

## Hit a target size

Work out the bitrate the file can afford:

```text
total kbit/s = size in MB × 8000 ÷ duration in seconds
video kbit/s = total − audio bitrate − a few percent for overhead
```

For a 60-second clip under 20 MB: 20 × 8000 ÷ 60 ≈ 2,666 kbit/s in total, so about 2,450 kbit/s for video with 128 kbit/s audio. Two-pass encoding lands close to the target:

```sh
ffmpeg -i input.mkv -c:v libx264 -preset slow -b:v 2450k -pix_fmt yuv420p -pass 1 -an -f null -
ffmpeg -i input.mkv -c:v libx264 -preset slow -b:v 2450k -pix_fmt yuv420p -pass 2 -c:a aac -b:a 128k -movflags +faststart output.mp4
```

Both passes need the same video options. `-movflags +faststart` puts the MP4 index at the front so playback can start before the whole file has loaded. If the bitrate comes out very low for the resolution, downscale (for example `-vf scale=-2:720`) or trim the clip; a sharp 720p video looks better than a blocky 1080p one.

CRF modes cannot promise a size. Single-pass bitrate modes, such as SVT-AV1's, can overshoot by several percent, so leave more margin. [Autocompressor](/tools/utilities/autocompressor/) does this calculation for you if you would rather not.