Video Bitrate Chart: What Bitrate to Use for 720p, 1080p and 4K

What is bitrate in video?

Bitrate is the amount of data a video spends on each second of playback. You'll see it written in megabits per second (Mbps) or kilobits per second (kbps), where 1 Mbps equals 1,000 kbps. A 1080p video at 8 Mbps uses 8 million bits to describe every second of picture; the same video at 2 Mbps has to describe that same second with a quarter of the data.

Two things follow from that. First, bitrate multiplied by duration is the file size — nothing else in the file comes close to mattering. Second, bitrate is a budget, not a quality score. The encoder decides how to spend it, and whether a given budget looks good depends on how many pixels it has to cover, how many frames per second, and which codec does the spending. That's why a single "best bitrate" doesn't exist, and why the chart below has a row per resolution and a column per frame rate.

Data rate and bitrate mean the same thing. Windows labels it "Data rate" in a video file's Properties, QuickTime calls it "Data Rate" too, and most other software says "bitrate". If you're looking at a file on Windows and see both "Data rate" and "Total bitrate", the first is the video track alone and the second adds the audio on top.

Video bitrate chart for 480p, 720p, 1080p, 1440p and 4K

These ranges are for H.264, the codec almost every device plays, and for a file you're going to watch or share as it is. The low end of each range is the point where I'd still call the picture clean; the high end is where extra bits stop making a visible difference on normal content.

Where you land inside a range depends on the footage. A screen recording, a slideshow or a talking head against a plain wall sits comfortably at the bottom. Handheld footage, water, foliage, confetti, fast game footage and anything shot in low light (where sensor noise counts as "detail" the encoder has to pay for) needs the top of the range, and sometimes more.

For a portrait phone video, read the row by the short edge. A 1080 × 1920 vertical clip has the same number of pixels as a 1920 × 1080 landscape one, so it belongs in the 1080p row.

YouTube's recommended bitrates, for comparison

YouTube publishes its own recommended upload bitrates. Here are its numbers for standard (SDR) video:

YouTube asks for HDR uploads to go roughly 25% higher again — 10 Mbps instead of 8 at 1080p, for example.

YouTube's figures sit at the top of my ranges or above them, and that's deliberate on its part. YouTube re-encodes every upload into its own streaming versions, and a re-encode can only work with what it receives. It wants a generous, clean source so its own compression has something to throw away. So if the video is going to YouTube, use YouTube's numbers. If the video is the final file — something you'll send, post somewhere with a size limit, or keep on a drive — the middle of my chart is plenty, and it's a much smaller file.

YouTube's small-resolution numbers are also relatively higher than mine. That matches how encoders behave: a small frame has fewer neighbouring pixels to predict from, so it needs a bit more data per pixel to look clean. The 480p and 720p rows of my chart are the ones I'd round up first.

Why the same bitrate looks fine at 720p and awful at 4K

The number that actually predicts how a video looks isn't bitrate on its own. It's bits per pixel per frame — the bitrate divided by the number of pixels the encoder has to fill every second:

bits per pixel = bitrate ÷ (width × height × frame rate)

A 4K frame has nine times the pixels of a 720p frame. Hand both the same 4 Mbps and the 720p video gets nine times as much data per pixel. That's why "is 4 Mbps a good bitrate?" has no answer until you say the resolution: 4 Mbps is generous at 720p30, a little soft at 1080p30, and a smeared mess at 4K.

When I built the compressor on this site, I planned every encode around bits per pixel instead of raw bitrate, and I tuned it against these reference points for H.264:

The chart at the top of this page is just that table multiplied out. 1920 × 1080 × 30 frames is about 62 million pixels a second; at 0.075 bits each that's 4.7 Mbps, and at 0.15 it's 9.3 Mbps. Once you know the formula, you can work out a sensible bitrate for any odd resolution a chart doesn't list — an ultrawide screen capture, a square Instagram crop, a 1080 × 1350 portrait post.

One caveat I learned the hard way: that table describes a first-generation encode, straight out of a camera or screen recorder. A clip that has already been through WhatsApp, Messenger or a TikTok download has lost its noise and fine texture — the expensive parts — so it can look fine at a bits-per-pixel figure that would look dreadful from a camera. My compressor used to read a re-shared clip's low bitrate as damage and "rescue" it by dropping the resolution, which turned a 1080p video into 480 × 270. Now it judges a source against itself, not against the table. If you're re-compressing something that has clearly been compressed before, don't chase the numbers on this page; every extra encode costs quality of its own.

What bitrate for 1080p 60fps?

For H.264, 7–14 Mbps covers 1080p at 60fps: about 10 Mbps for everyday footage, the top of the range for fast games and sports. YouTube recommends 12 Mbps for 1080p60 uploads.

You might expect 60fps to need double the bitrate of 30fps, since there are twice as many frames. It doesn't, and the reason says a lot about how video compression works. Most frames in a video don't store a full picture — they store only what changed since the previous frame. At 60fps, consecutive frames sit half as far apart in time, so less changes between them and each one costs less to describe. In practice 60fps needs about 1.5 times the bitrate of 30fps, which is exactly the step YouTube uses (8 to 12 Mbps at 1080p, 16 to 24 at 1440p). My 60fps column follows the same rule.

When bits are short, frame rate is also the first thing I'd give up. If a size limit forces a 1080p60 game clip down below 720p, my compressor halves the frame rate to 30 and spends the freed-up budget on resolution instead. Thirty sharp frames look better than sixty mushy ones, and nobody watching a clip in a chat window misses the extra frames nearly as much as they notice the blur.

What bitrate for 4K?

For H.264, 4K needs 19–37 Mbps at 30fps and 28–56 Mbps at 60fps. YouTube asks for 35–45 Mbps (30fps) and 53–68 Mbps (60fps) for 4K uploads.

Those numbers make 4K files large fast: 45 Mbps is about 340 MB per minute. That's the practical reason most 4K video you'll ever handle is HEVC rather than H.264 — the codec section below explains why that cuts the numbers by roughly a third. It's also why 4K is the first thing I'd question if you need a small file. Unless the video will actually be watched on a 4K screen, dropping it to 1080p before compressing gives a sharper result at any given file size, because the encoder spends its budget on a quarter as many pixels. Resolution is the setting people underuse when they're trying to shrink a video.

How the codec changes the numbers: H.264, H.265, VP9 and AV1

Every figure above assumes H.264 (also called AVC). Newer codecs hold the same picture in fewer bits. These are the conversion factors my compressor uses — conservative mid-points of published codec comparisons, not best-case marketing numbers:

This matters in both directions. If you export HEVC, you can divide the chart by about 1.45. And if you're converting HEVC to H.264 — which happens every time someone makes an iPhone video play on an older Windows PC — the H.264 version needs more bitrate than the original to look the same. iPhones record HEVC by default on the "High Efficiency" camera setting, so an iPhone clip at 10 Mbps is carrying roughly what 14–15 Mbps of H.264 would. My compressor always writes H.264 because everything plays it, so it converts the source's bitrate into H.264 terms before it decides anything; otherwise it would mistake an efficient HEVC file for a starved one and squeeze it too hard.

YouTube's live-streaming guidance shows the same gap: for 1080p30 it suggests 10 Mbps in H.264 but only 3–8 Mbps in HEVC or AV1. If you want the fuller H.264 versus H.265 trade-off — encode time, compatibility, and when HEVC isn't worth it — my Handbrake settings guide covers it.

Bitrate and file size: the math

File size is bitrate times duration, divided by eight to turn bits into bytes:

size in MB = (video Mbps + audio Mbps) × seconds ÷ 8

A 5-minute 1080p video at 8 Mbps with 128 kbps audio: (8 + 0.128) × 300 ÷ 8 ≈ 305 MB. Here's what common bitrates cost per minute:

Run the formula backwards and you get the bitrate a size limit allows: bitrate = size × 8 ÷ seconds. A 25 MB limit on a one-minute clip gives you 25 × 8 ÷ 60 ≈ 3.3 Mbps for video and audio together. That's the whole job a "compress to 25MB" tool does — the size and the length fix the bitrate, and everything else has to fit inside it.

The interesting part is what happens next. Here's what my online video compressor actually produces when you give it a typical phone clip (1080p, 30fps, around 16 Mbps) and a target size. The cells show the resolution it chooses and the video bitrate it lands on:

*The source only had 16 Mbps to begin with, so the compressor stops there — spending more bits than the original had would only make the file bigger without adding any detail.

Notice that it steps the resolution down rather than cramming a thin bitrate into a full 1080p frame. Three minutes at 25 MB leaves under 1 Mbps for video. At 1080p that works out to about 0.015 bits per pixel, deep in "falling apart" territory; at 540p the same budget covers a quarter of the pixels and looks like a clean, smaller video instead of a blocky big one. The audio also shrinks with the budget: it gets 128 kbps stereo when there's room, and drops to 64 kbps mono on the tightest budgets, where stereo would steal bits the picture needs more.

Two small notes on those numbers. My compressor counts a megabyte as 1,048,576 bytes, which is why the budgets come out slightly above the round-number math; different systems count megabytes differently, and it's a common reason a file that "should" fit gets rejected. And it aims a few percent under the target on purpose, because encoders overshoot more often than they undershoot. If you're fitting a clip under a chat app's upload cap, the Discord video compressor has the size presets built in.

What bitrate should I stream at?

Live streaming flips the problem. With a file, you pick a bitrate and wait for the encode. With a stream, your upload speed sets the ceiling, and the encoder has to keep up in real time — which means it can't be as clever as an offline encode and needs more bitrate for the same picture.

YouTube's recommended H.264 bitrates for live streams:

YouTube also recommends a keyframe every 2 seconds and 128 kbps stereo audio. Twitch has long recommended staying around 6,000 kbps (6 Mbps) for 1080p60 on standard H.264 streams, well below YouTube's figure. It has been changing its limits for streams that use its Enhanced Broadcasting feature, so check Twitch's current broadcasting guidelines before you set OBS.

My rule of thumb: run a speed test, and keep the stream bitrate at no more than about three quarters of your measured upload speed. Upload speed wobbles, and a stream that uses every last bit of it will drop frames the moment your connection dips. If your upload can't cover the bitrate the chart says your resolution needs, stream at 720p60 or 936p — a clean lower resolution beats a blocky 1080p every time.

Streams use constant bitrate (CBR) because the platform needs a steady flow. Files don't need that, and shouldn't use it: a variable bitrate or quality-based encode (CRF) spends more on hard scenes and less on easy ones, which gives better quality for the same file size.

How to check a video's bitrate

Windows: right-click the file, choose Properties, open the Details tab, and look under Video for "Data rate" (the video track) and "Total bitrate" (video plus audio).

Mac: open the video in QuickTime Player and choose Window → Show Movie Inspector. It lists the data rate along with the resolution and frame rate.

VLC, on any system: play the file, then open Tools → Media Information (Window → Media Information on a Mac) and check the Statistics tab. The input bitrate there moves while the video plays, which is a nice way to see variable bitrate in action — it jumps on busy scenes and drops on still ones.

No software at all: divide the file size by the duration. A 150 MB file that runs 2 minutes: 150 × 8 ÷ 120 = 10 Mbps total. That's the average, audio included, and it's accurate enough to tell you which row of the chart the file belongs in.

Is a higher bitrate always better?

Only up to a point, and only if the detail exists in the first place.

Past the top of each range in the chart, extra bitrate mostly preserves camera noise and grain nobody can see at normal viewing size. The file keeps growing; the picture doesn't visibly improve.

And bitrate can't create detail that isn't in the source. Re-encoding a 2 Mbps download at 10 Mbps gives you a five-times-bigger file with exactly the same blur, because the encoder can only describe what it receives. I hit a version of this in my own compressor: a clip with a thin 684 kbps video track and a 48 kbps audio track came out 10% larger after "compression", because the audio got re-encoded at a standard 128 kbps. Now the compressor never spends more on a track than the source did. If a video looks soft because it was compressed too hard somewhere upstream, a higher bitrate won't fix it — here's how to tell which kind of blur you're dealing with and what can actually help.

Audio has its own version of this; the same logic about where extra bits stop mattering applies to MP3 bitrates like 128, 192 and 320 kbps.

Frequently asked questions

Sources

• YouTube recommended upload encoding settings — YouTube Help
• Choose live encoder settings, bitrates, and resolutions — YouTube Help
• Broadcasting guidelines — Twitch Help