What bitrate do you need for 1080p?

Short answer: about 2 Mbps is the floor where 1080p still holds together, 4–5 Mbps looks good for most footage, and 8 Mbps is generous enough for fast motion. Below 2 Mbps, 720p at the same bitrate looks better than 1080p does.

The longer answer is worth having, because "what bitrate for 1080p" has no single number — it depends on how much is moving.

The ladder

These are the floors this tool uses: the lowest video bitrate at which each resolution still reads as video rather than as blocks, for H.264.

Resolution	Floor	Comfortable	Generous
2160p (4K)	8 Mbps	15–25 Mbps	35+ Mbps
1440p	4 Mbps	8–12 Mbps	16 Mbps
1080p	2 Mbps	4–5 Mbps	8 Mbps
720p	1 Mbps	2.5–3 Mbps	5 Mbps
480p	500 kbps	1–1.5 Mbps	2.5 Mbps
360p	300 kbps	600–800 kbps	1.2 Mbps
240p	150 kbps	300–400 kbps	600 kbps

"Floor" is the operational number: at or above it the resolution is worth keeping, below it you are better off dropping a rung. That is exactly how the compressor here decides — it works out how much bitrate your target size allows, then picks the highest resolution whose floor that bitrate clears.

Why the range is so wide

Bitrate requirements scale with how much changes between frames, because that is what the encoder actually stores. Three examples at 1080p:

• A talking head on a static background. Almost nothing moves between frames. 1.5 Mbps can look genuinely good — below the nominal floor — because the encoder has very little new information to describe each frame.
• A handheld walk through a city. Every pixel changes every frame, including fine detail in foliage and crowds. 8 Mbps is not excessive.
• A screen recording of code. Mostly static, but the moving parts are sharp high-contrast text, which is expensive. Scrolling is the worst case: everything moves at once and all of it has hard edges.

So the floors above are deliberately conservative — set where the hard cases still survive, not where the easy ones do. If your footage is a static-camera talking head, you have more room than the table suggests.

Working backwards from a size limit

This is the calculation that actually matters when you have a limit to hit.

available video bitrate = (target bytes × 8 ÷ duration) − audio bitrate

For a 5-minute clip into Discord's 20MB:

20,000,000 bytes × 8        = 160,000,000 bits
÷ 300 seconds               = 533,000 bits/sec total
− 128,000 for stereo audio  = 405,000 bits/sec for video

405 kbps. That clears the 360p floor (300 kbps) but not 480p (500 kbps) — so 360p is the honest answer for a 5-minute clip into 20MB. Trying to hold 1080p at 405 kbps would be five times under its floor and would look broken.

Two things that calculation shows which are easy to miss:

Audio is not free. 128 kbps across five minutes is 4.8MB — a quarter of a 20MB budget. Dropping to 64 kbps mono releases 2.4MB, which is a 60% increase in the video bitrate. On tight targets that is a bigger quality win than any encoder setting, which is why this tool steps audio down through 128 kbps stereo, 64 kbps mono, then 32 kbps mono rather than starving the picture.

Duration dominates everything. The same 20MB gives a 30-second clip 5.2 Mbps — comfortable 1080p — and a 20-minute clip 133 kbps, which is below the bottom of the ladder. If you are unhappy with the resolution you are being offered, the lever is almost always length.

Your source bitrate is a ceiling

Re-encoding cannot add information that was never recorded. If your source is 1080p at 3 Mbps, encoding it at 8 Mbps produces a larger file that looks identical — you are spending bits describing the first encoder's artefacts in high fidelity.

So the practical ceiling is your source bitrate. Target below it, and never re-encode upward.

A note on CBR versus VBR

Variable bitrate spends more on hard scenes and less on easy ones, which gives better quality for the same average — but the average is only enforced across the whole file, so the final size is unpredictable. That unpredictability is fine for streaming and a real problem when you have a hard byte limit.

Constant bitrate is more predictable and therefore safer against a limit, at some quality cost on varied content. This tool uses CBR for exactly that reason, and then measures the output anyway — because even CBR encoders miss their target, and a file that came in 3% over a Discord limit is a failed upload regardless of how good it looks.

FAQ

Is 1080p at 2 Mbps good?

It is acceptable rather than good — 2 Mbps is the floor where 1080p holds together. For a static-camera talking head it looks fine. For anything with real motion you will see softness in the detailed areas. 4–5 Mbps is where 1080p stops being a compromise.

Should I use 720p or 1080p for a small file size?

Work out the bitrate your target allows: target bytes × 8 ÷ duration − audio. If the answer is above 2 Mbps, keep 1080p. If it is between 1 and 2 Mbps, 720p will look better. Below 1 Mbps, drop to 480p. Holding on to a resolution the bitrate cannot sustain is the most common cause of bad-looking compressed video.

What bitrate is 4K?

Around 8 Mbps is the floor, 15–25 Mbps is comfortable, and streaming services deliver 4K at roughly 15–25 Mbps with modern codecs. Note that 4K is rarely the right choice when you are compressing to a size limit — the pixels consume budget that would produce a better-looking 1080p file.

Does a higher bitrate always mean better quality?

Only up to the point where it exceeds what the source actually contains. Beyond that you are describing the previous encode's artefacts more precisely, which costs bytes and changes nothing you can see. Your source bitrate is the practical ceiling.