The number that decides
Bitrate is how much data your video spends per second of runtime. It decides file size, upload time, and how much of your image survives. Here is where the ceilings sit and what the number really controls.
No credit card required. Cancel any time.
Updated September 2026
The definition
Megabits per second measures how much data describes each second of picture. Multiply by runtime, divide by 8, and you have the file size. Starve the number and the encoder starts approximating.
A 100 Mbps export means every second of your film is described by 100 megabits of data, about 12.5 megabytes. The encoder decides how those bits get spent: sharp edges, film grain, and fast motion are expensive; flat walls and locked-off shots are cheap. Give it a generous budget and the picture keeps its texture. Cut the budget by 90 percent and it keeps the composition but swaps the expensive parts for approximations.
File size follows directly: bitrate times duration, divided by 8 bits per byte. No codec cleverness changes that arithmetic. Codecs only change how good the picture looks at a given rate.
7.5 GB
10 minutes at 100 Mbps
100 megabits x 600 seconds / 8 bits per byte = 7,500 megabytes.
45 GB
1 hour at 100 Mbps
Same arithmetic, 3,600 seconds. The relationship stays linear at any scale.
1.65 GB
10 minutes at 22 Mbps
The same cut at Vimeo's published 4K delivery ceiling. 5.85 GB of picture information is gone.
The myth
A 4K badge on a stream tells you how many pixels arrive. It says nothing about whether those pixels carry real information or compression artifacts.
Divide the bit budget by the pixels and the myth collapses. A UHD frame holds 8.3 million pixels, four times as many as 1080p. Stream 4K at 12 Mbps, which is Vimeo’s own ceiling for 2K playback, and at 24 frames per second each pixel in each frame gets about 0.06 bits. A 1080p stream at 20 Mbps gives each pixel about 0.4 bits, nearly seven times the data per pixel.
A starved encoder does predictable damage: it quantizes coarsely, so gradients turn into bands, grain smears into plastic, and shadows collapse into blocks. The result is a technically-4K image that looks softer than well-fed 1080p, because sharpness lives in the bits, not the pixel count. The mechanics of that damage are the subject of our guide to video compression.
Content decides how many bits a picture needs, and the big streamers act on it. When Netflix moved to per-shot encoding, its highest 4K rung averaged 8 Mbps across 100 titles, ranging from 1.8 Mbps for clean animation to 17.2 Mbps for detail-rich action. Same resolution, a ninefold spread in bits, because the bits follow the complexity of the image.
Upload targets
YouTube publishes recommended upload bitrates by resolution and frame rate. These are input numbers: what its encoder wants to work from, not what it streams back out.
YouTube's recommended H.264 upload bitrates, read from support.google.com, September 2026. YouTube re-encodes every upload before delivery.
Upload above the recommendation and nothing is wasted: the re-encode has more to work from. Upload below it and you compress twice from a thin source. Either way your file is only the input; every viewer watches YouTube’s own encode of it.
Delivery ceilings
Whatever you export, mainstream platforms re-encode it to their own delivery ladder. The ceilings are published or measurable, and they are low.
Your 4K master on uncompressed.io, streamed as uploaded
Vimeo 4K ceiling
YouTube 4K, measured
Vimeo's 22 Mbps 4K maximum is published in its playback guidelines; the YouTube figure was measured from a delivered 4K stream, August 2026. The 150 Mbps example sits inside the 100 to 150 Mbps band desktop browsers decode without dropped frames.
The ceilings are bandwidth economics, not malice. Netflix tells subscribers that 4K needs only a 15 Mbps connection, and its per-shot encodes are built to fit under it. For a series on a living-room TV, that trade is rational. For a colorist checking a grade or a client judging your reel, it throws away exactly the information being judged.
Hosting that skips the re-encode is the exception rather than the rule. uncompressed.io streams the exact bytes you upload: a 150 Mbps export plays at 150 Mbps, and desktop hardware decoders stay comfortable through the 100 to 150 Mbps band. What serving masters takes, and how to verify a host is not quietly transcoding you, is covered in video hosting without compression.
Two jobs, two numbers
Export twice. The master preserves everything for the future; the delivery version is tuned for the pipe it travels.
A master is insurance against the next re-encode. Apple rates ProRes 422 HQ as visually lossless through many generations at roughly 220 Mbps for 1080p at 29.97 fps, and the target climbs to 884 Mbps for UHD at 30p. Those numbers look extravagant next to streaming ladders because they solve a different problem: surviving being re-edited, re-graded, and re-compressed. Flavor-by-flavor rates and the file-size math are in our ProRes delivery guide.
Delivery is where you spend less, deliberately. For client-facing streaming, export a high-bitrate H.264 or HEVC file inside the 100 to 150 Mbps browser band and host it somewhere that will not re-encode it. Review workflows run the same way: our review rooms stream your delivery file at its full rate, with timecoded notes landing on the exact frame.
VBR vs CBR, briefly
Questions
For the same codec and the same content, more bits mean fewer compression artifacts, with diminishing returns once the encoder has what it needs. Masters deliberately overspend: Apple rates ProRes 422 HQ at about 220 Mbps for 1080p so it stays visually lossless through generations of editing. For delivery, the practical ceiling is whatever the platform or the viewer's hardware will pass through, which is why where you host matters as much as what you export.
For YouTube uploads, its published recommendation is 35 to 45 Mbps for SDR at 24 to 30 fps and 53 to 68 Mbps at 50 or 60 fps. For an edit master, use your codec's own target, for example ProRes 422 HQ at 884 Mbps for UHD 30p. For streaming the file itself without a re-encode, an export in the 100 to 150 Mbps range plays smoothly in modern desktop browsers.
Because the platform re-encoded it. Mainstream hosts transcode every upload into their own adaptive ladder, and the player serves a rung sized for their bandwidth budget: Vimeo caps 4K at 22 Mbps, and Netflix's average top 4K rung is about 8 Mbps. Your file was the input to their encoder, not the thing being streamed.
Yes. File size is bitrate times duration divided by 8, so doubling the bitrate doubles the size: 10 minutes at 100 Mbps is 7.5 GB, and at 200 Mbps it is 15 GB. Audio tracks and container overhead add a little on top, but for video-dominated files the relationship is straight multiplication.
Resolution is how many pixels each frame contains; bitrate is how much data describes them per second. The two are independent: a 4K stream at a starved bitrate can look worse than 1080p at a generous one, because banding, blocking, and smeared detail come from missing bits, not missing pixels.
uncompressed.io streams the exact bytes you upload. No re-encode, no bandwidth caps, no platform branding, on every plan.