Discord Video Pixelated? Fit the Size Limit Cleanly

You record a good clip, drop it into Discord, and it either refuses because it is too big, or it uploads and looks like a watercolor. The cause is nearly always the same: a file that was forced under a size limit without enough thought about where the bits go.

The fix is arithmetic, not magic. Once you know how many bits you have per second of video, you can pick the right resolution and settings, and the result will be as clean as that budget allows.

The limit, and why it keeps moving

Discord’s upload limits have changed several times, and different sources disagree because they were written at different moments. When I checked in late October 2026, Discord’s own help material said the free upload limit had been raised to 20 MB on August 14, 2026, up from 10 MB, with higher limits for Nitro and for boosted servers. Sources disagree about the larger Nitro figures, so I will not quote one. Check the number that your app shows when you try to upload, since it is the one that counts today.

Discord’s help pages also list the supported video codecs for MP4 as H.264, HEVC and AV1. H.264 plays everywhere and is the safe choice. A 20 MB cap is tight for video, and everything below follows from that.

Why files get blocky when squeezed

A video’s size is roughly its bitrate multiplied by its duration. If you have 20 MB and a 60 second clip, you have about 2.7 Mbps in total, and that has to cover video and audio. If you have a 3 minute clip, the budget falls to under 1 Mbps. At 1080p, those numbers are far below what looks clean.

I measured how quality falls with bitrate on a 1080p clip: 1 Mbps scored 31.0 dB PSNR, 2 Mbps scored 34.4 dB, 4 Mbps scored 38.3 dB and 8 Mbps scored 42.4 dB. Below about 2 Mbps, the picture degrades quickly. That is where the “pixelated” look comes from. It is not that Discord is doing something bad, it is that your file is carrying too little information per second.

Do the bitrate math

The formula is simple. Take the size limit, leave a margin, convert to bits and divide by the duration.

target_total_kbps = (size_MB * 8 * 1000 * 0.92) / seconds
video_kbps = target_total_kbps - audio_kbps

The 0.92 leaves about 8 percent safety, because container overhead and variation can push a file over the limit. Some people use megabytes of 1000 kB and some of 1024, so a margin protects you.

Worked examples for a 20 MB limit and 96 kbps audio:

Clip length	Total budget	Video budget
15 s	about 9.8 Mbps	about 9.7 Mbps
30 s	about 4.9 Mbps	about 4.8 Mbps
60 s	about 2.45 Mbps	about 2.35 Mbps
2 min	about 1.2 Mbps	about 1.1 Mbps
4 min	about 0.6 Mbps	about 0.5 Mbps

Now match resolution to the budget. In my 720p versus 1080p test, 720p was equal or better at about 1 Mbps, they were close at 2 Mbps, and 1080p won clearly from 4 Mbps. So:

• Under about 1.5 Mbps: use 720p. In my test it was a hair ahead of 1080p, and it decodes lighter on weak phones.
• Between 1.5 and 4 Mbps: either works. For calm content, 1080p was still slightly ahead at 2.35 Mbps, and for busy content I would pick 720p.
• Above 4 Mbps: 1080p.

The details are in 720p versus 1080p, does it matter.

The best lever is the clip length

Trim the clip. If you are sharing a moment, cut to the part that matters. Halving the duration doubles the bitrate you can afford. A 30 second highlight at 4.8 Mbps looks far better than a 60 second clip squeezed to 2.4 Mbps. Cut dead time at the start and the end, and consider splitting a long video into two messages.

Use a proper encoder pass

You have three common ways to hit a target size, and they differ in quality.

Single pass average bitrate. The encoder guesses how hard the video is. It works, but it may miss the size and spread bits unevenly.

Two pass. The first pass studies the video, and the second distributes bits to where they are needed. It is the standard way to hit a size.

Constant quality with a cap. Choose a CRF and a maximum bitrate. Quality is steady, and the cap limits the size. You must check the result, and may need to rerun at a higher CRF.

I tested these on a 10 second 1080p clip with a 2 Mbps target, so a 2,500 kB budget:

Method	File size	PSNR
Single pass ABR 2,000 kbps	2,470 kB	34.69 dB
Two pass 2,000 kbps	2,625 kB	35.27 dB
CRF 27 with a 3 Mbps cap	3,969 kB	37.45 dB

The numbers need to be read carefully. The single pass landed under target. The two pass ended 5 percent over the nominal target and scored about 0.6 dB higher, which is mostly explained by those extra bytes. The constant quality version scored highest, but at 3,969 kB it is far above the budget, so it is not a fair comparison. The lesson is that the simple methods landed within about 5 percent of the target here, and two pass is not a dramatic win by itself. For a hard limit, check the file size afterwards and keep a margin. If you overshoot, lower the bitrate and run again.

A command that works

Two-pass encoding for a 30 second clip aiming at 4.5 Mbps video:

ffmpeg -y -i clip.mp4 -c:v libx264 -preset slow -b:v 4500k \
  -pass 1 -an -f null /dev/null
ffmpeg -i clip.mp4 -c:v libx264 -preset slow -b:v 4500k \
  -pass 2 -c:a aac -b:a 96k -movflags +faststart discord.mp4

On Windows replace /dev/null with NUL. To drop to 720p for a lower budget, add a scale filter to both passes:

-vf "scale=-2:720:flags=lanczos"

Then check the size. If it is over, reduce the video bitrate by about a tenth and run again.

A direct test at the Discord budgets

To put real numbers on the resolution choice for size-limited clips, I ran a test with the two budgets from the table above. I took a 5 second 1080p clip, and for each of two video bitrates (1.1 Mbps, which is what a 2 minute clip would get, and 2.35 Mbps, which is a one minute clip) I encoded it at 1080p, 720p and 540p with two passes at the slow preset. For comparison I scaled each result back up to 1080p and measured PSNR against the original.

Video bitrate	Resolution	File size	PSNR
1.1 Mbps	1080p	773 kB	32.53 dB
1.1 Mbps	720p	731 kB	32.76 dB
1.1 Mbps	540p	714 kB	32.28 dB
2.35 Mbps	1080p	1,572 kB	35.89 dB
2.35 Mbps	720p	1,510 kB	34.84 dB
2.35 Mbps	540p	1,486 kB	33.53 dB

Three things stand out. First, at the very low budget the three resolutions are within half a decibel of each other, with 720p on top. At that point, none of them looks good, and the choice matters less than trimming the clip. Second, at 2.35 Mbps, 1080p was a full dB ahead of 720p and 2.4 dB ahead of 540p, so a one minute clip does not have to drop to 720p to stay clean. Third, the file sizes: even with two passes, a 5 second clip overshot its nominal target by roughly 7 to 12 percent (1,572 kB against the 1,469 kB you would expect at 2.35 Mbps). Short clips give the rate control little room to correct, so for a hard limit leave a margin larger than you think you need, and always check the finished file.

I should say what the test does not show. It uses PSNR after scaling back up, which favors resolutions close to the original, and one clip of an animated film. On a phone screen, the smaller encodes may look closer to the big one than the numbers suggest. Use the numbers as a starting guess, and look at your clip.

Screen sharing is a different thing

People sometimes mix up sharing a recorded clip with live screen sharing. Live screen share quality has its own rules, which are set by your account and the server, and from what I found, free users are limited to 720p at 30 fps while higher tiers get more. If the live stream looks blocky, it is a different problem from an uploaded clip: it is limited by your upload speed and the live encoder. Lowering the frame rate for text-heavy content, and choosing the “prioritize clarity” kind of option if the app offers one, usually looks better than keeping a high frame rate.

Audio budget

For a short clip, audio costs very little: 96 kbps AAC is only 12 kB per second, or 720 kB per minute. At a very small file size it is still worth choosing mono for voice-only content, or lowering the audio to 64 kbps, to save a few percent. But do not cut audio too hard, since crunchy sound makes the whole clip feel worse. If the clip has no useful sound, remove the audio track altogether and use the whole budget for video:

ffmpeg -i clip.mp4 -an -c:v libx264 -b:v 5000k -preset slow out.mp4

Why not just let Discord handle it?

Discord, like most chat apps, may compress or transcode what you send, or it may reject files over the limit. When it compresses, you lose control over how, and the settings are typically chosen for speed and size rather than looks. Preparing the file yourself gives you the decision. It also means the clip looks the same for everyone, regardless of device.

If you send the same clip into several servers, upload it once and share the link or forward the message, so that you do not create several slightly different copies.

Tools you can use

You do not need the command line. HandBrake lets you set a constant quality or an average bitrate, choose the resolution and trim the clip. Some video editors let you set a bitrate on export. Online compressors exist too, but check what they do, since many reduce the resolution drastically and apply heavy compression, and some leave watermarks. Whichever you use, check the exported file size, look at the hardest part of the clip, and compare with the original.

For HandBrake users, the article on why HandBrake output looks pixelated describes the settings that matter.

Fixing a clip that is already blocky

If the video you have is already pixelated, you can limit further damage. Do not compress it again at a high ratio. Compress once, from the best source you have. If the original recording exists, go back to it.

If the original is gone, a cleanup can smooth the blocks before the final compression, and it also helps the encoder, since smoother input compresses better. You can see what that does on a short sample with the free preview.

Screen recordings are a special case

A lot of Discord clips are game or screen recordings. These have sharp text, fast motion and effects. Record at a high bitrate first, then compress once for Discord. If your recorder offers a quality mode, use it. The article on OBS recordings that look pixelated when moving covers the recording side. For the sharing step, consider lowering the frame rate from 60 to 30 for a small clip, since halving the frames roughly doubles the bits per frame, though motion will be less smooth.

Phone clips

On a phone, the Discord app may compress a video before sending, and the details have varied. I found a note that on mobile the size is now checked before Discord compresses the video, which suggests a large phone video may be rejected rather than silently shrunk. If that is what you see, compress it yourself first, at a target below the limit, so that you decide how the compromise is made rather than leaving it to the app.

Many phone gallery apps have a built-in trim and a compress option. If you use a compression app, check the output at full size, since some apps use very low bitrates.

Other ways to share a longer or better clip

If the clip needs to be sharp or long, a size-limited upload may be the wrong tool. Alternatives:

• Upload to a video host or a cloud drive and post a link. Discord will usually show an embed or a link preview.
• Split it into two or three parts at natural cuts.
• Use a server with a higher limit if you have one.
• Share a GIF or a short loop only for tiny moments, though GIF files are often larger and worse looking than a short MP4.

A short routine you can repeat

Once you have worked through it once, the whole thing takes a couple of minutes. Check the limit in the app. Trim the clip to what matters. Divide the limit, less 8 percent, by the number of seconds, and subtract the audio. If the result is below about 1.5 Mbps, choose 720p, otherwise stay at 1080p. Encode with two passes. Look at the file size and the hardest few seconds. If it is over the limit, reduce the bitrate by 10 percent and run it again.

Keep the original recording until you are happy with the result. If the limit changes again next month, as it has before, you can simply repeat the steps with the new number, without having to start from a degraded copy.

Mistakes I would avoid

Compressing a compressed copy. If you already shrank a clip once and it is still too big, go back to the original rather than shrinking the small copy again. Each pass loses detail, and in my five-pass test the quality kept falling by 1 dB or more per generation.

Choosing the resolution by habit. A clip does not have to be 1080p. Pick the resolution the bitrate can carry.

Forgetting the audio. A large audio track on a tiny budget wastes bits, and a tiny one makes speech muddy. Aim for 64 to 128 kbps.

Cutting it too close to the limit. A file that is 20.1 MB will be refused. Aim for 90 to 92 percent of the limit, and check.

Summary

Discord clips look pixelated when too few bits are spread over too many pixels and too much time. Work out the bitrate from the size limit and the duration, choose 720p when the budget is under about 1.5 Mbps, trim the clip, and compress once from the original with two passes or a capped quality mode. Check the limit in the app because it has changed, and keep a safety margin of about 8 percent.