Bitrate, duration and size are one equation with three unknowns
A video file is a stream of bits delivered at an average rate over a fixed time, so its size is fixed the moment you choose two of those three quantities. Bitrate is measured in bits per second; size is measured in bytes; the only conversions you need are the factor of 8 between bits and bytes and the factor of 1000 between kilo and mega in decimal units.
Read the relationship in whichever direction your problem runs. Encoding a lecture at 4 Mbps for 90 minutes? Multiply and you get the size. Need a 2-hour programme to fit under 4 GB for a memory card? Divide and you get the bitrate. Both are the same line of algebra, and the only subtlety is remembering that audio takes its share first: an encoder given a 5000 kbps total budget with 192 kbps of AAC has 4808 kbps left for pictures.
Two conventions cause most of the confusion. Bitrates are always decimal — 1 Mbps is exactly 1,000,000 bits per second, never 1,048,576. File sizes are quoted decimally by encoders, storage vendors and this calculator, but Windows displays them in binary units while still writing the label “MB”. IEC 80000-13 fixed this by defining MiB (2²⁰ bytes) and GiB (2³⁰ bytes) as separate units, which is why a 4.7 GB DVD holds 4.38 GiB and why a 4 GiB FAT32 limit is really 4295 MB.
The formula, and why bits per pixel is the number that matters
The size equation is S = (b_v + b_a) × t ÷ 8 ÷ 1000, with bitrates in kbps, time in seconds and the result in decimal megabytes. Divide by 8 to get from kilobits to kilobytes, then by 1000 to get from kilobytes to megabytes. Reverse it for the target-size case: b_v = S × 8 × 1000 ÷ t − b_a. Notice that the audio subtraction happens last and can push the video allocation negative, which tells you the target is impossible rather than merely tight.
Bitrate on its own says nothing about quality, because the same bitrate has to cover wildly different amounts of picture. 5 Mbps is luxurious at 640×360 and thin at 3840×2160. The normalising quantity is bits per pixel per frame: divide the video bitrate in bits per second by the number of pixels encoded per second, which is width × height × frame rate.
That single number lets you compare a 24 fps film transfer with a 60 fps game capture on equal terms. It is a rule of thumb, not a specification: a codec with better tools spends fewer bits for the same picture, so an HEVC or AV1 encode holds up at a bits-per-pixel figure where H.264 would visibly break. Content matters just as much — film grain, water, foliage and confetti are expensive; a static slide deck is nearly free.
The upload estimate is the same arithmetic applied to the finished file: seconds = S × 8 ÷ upload Mbps, since a megabyte is 8 megabits. Real transfers run below the line rate because of protocol overhead and contention, so treat the answer as a floor.
Worked example: one hour of 1080p at 8 Mbps
You are exporting a one-hour 1920×1080 programme at 30 fps, targeting 8 Mbps for video with a 192 kbps stereo AAC track, and you want to know the size and the upload time on a 50 Mbps connection.
- Convert the running time. 60 minutes = 3600 seconds.
- Total bitrate. 8000 kbps video + 192 kbps audio = 8192 kbps.
- Total bits. 8192 × 3600 = 29,491,200 kilobits.
- Convert to bytes. 29,491,200 ÷ 8 = 3,686,400 kilobytes.
- Convert to megabytes. 3,686,400 ÷ 1000 = 3686.4 MB, or 3.686 GB.
- Per hour. The programme is exactly an hour, so the data rate is also 3.686 GB per hour, and 61.44 MB per minute.
- Bits per pixel. Pixels per second = 1920 × 1080 × 30 = 62,208,000. Video bits per second = 8,000,000. So bpp = 8,000,000 ÷ 62,208,000 = 0.1286.
- Upload time. 3686.4 MB × 8 = 29,491.2 megabits. At 50 Mbps that is 589.8 seconds, or 9.83 minutes.
Now run it backwards. Suppose the same hour has to fit in 700 MB. Total bitrate = 700 × 8 × 1000 ÷ 3600 = 1555.56 kbps. Reserve 128 kbps for audio and the video gets 1427.56 kbps. At 1920×1080p30 that is 1,427,560 ÷ 62,208,000 = 0.023 bits per pixel — far too lean for HD, which is exactly the signal to drop the output to 720p or shorten the programme.
How to read the result
Check bits per pixel before you accept a bitrate. Encoder operators generally treat something around 0.1 bpp as a normal delivery allocation for H.264 and regard figures below about 0.05 bpp as the point where blocking and mosquito noise appear on demanding shots. These are working rules of thumb, not thresholds from any standard, and they move with the codec: AV1 and HEVC hold together lower than H.264, and VP9 sits between them.
Watch the trade you are actually making. At a fixed bitrate, every extra pixel and every extra frame costs picture quality, because the same bits are spread thinner. Halving the frame rate from 60 to 30 doubles bits per pixel at no cost in bitrate; dropping 2160p to 1080p quadruples it. That is why streaming ladders pair each resolution with its own bitrate rather than sending one number for everything.
Compare the total bitrate against the upload speed if the file is going out live. A 12 Mbps encode cannot be streamed over an 8 Mbps upstream link no matter how patient you are, though it uploads as a file perfectly well. For recorded uploads, use the time estimate as a floor and add margin: TCP overhead, packet loss and shared links all pull real throughput below the advertised rate, as the data transfer time calculator models in more detail.
Finally, mind the units when the size lands near a hard limit. 4 GiB — the FAT32 ceiling — is 4295 MB in decimal terms, so a file the encoder reports as 4200 MB still fits while one reported as 4400 MB does not. The same gap explains why a “4.7 GB” DVD shows as 4.38 GB in Windows.
Typical bitrates and one-hour file sizes by resolution
| Format | Video bitrate | Bits per pixel | One hour (MB) | Per hour (GB) |
|---|---|---|---|---|
| 640×360, 30 fps | 1 Mbps | 0.1447 | 536.4 | 0.536 |
| 1280×720, 30 fps | 2.5 Mbps | 0.0904 | 1211.4 | 1.211 |
| 1280×720, 60 fps | 4 Mbps | 0.0723 | 1886.4 | 1.886 |
| 1920×1080, 30 fps | 5 Mbps | 0.0804 | 2336.4 | 2.336 |
| 1920×1080, 30 fps | 8 Mbps | 0.1286 | 3686.4 | 3.686 |
| 1920×1080, 60 fps | 12 Mbps | 0.0965 | 5486.4 | 5.486 |
| 3840×2160, 30 fps | 25 Mbps | 0.1005 | 11,336.4 | 11.336 |
| 3840×2160, 60 fps | 45 Mbps | 0.0904 | 20,336.4 | 20.336 |
Every figure in this table is recomputable from the two formulas above. The bitrates shown are common delivery choices, not requirements: your own footage may need more or less depending on motion, grain and codec.
Mistakes that make a size estimate wrong
- Forgetting the audio track. 192 kbps sounds trivial next to 8 Mbps, but over two hours it is 172.8 MB. On a tight target it can be the difference between fitting and not.
- Mixing bits and bytes. Mbps is megabits per second; MB/s is megabytes per second. The factor of 8 between them is the single most common error in transfer and encode planning.
- Mixing decimal and binary prefixes. A 4 GiB limit is 4295 MB, not 4000 MB. IEC 80000-13 exists precisely so these can be told apart.
- Assuming a variable-bitrate encode hits its number exactly. Constant-rate-factor encoding targets quality, not size, so the finished file can land well above or below the estimate. Use two-pass or capped VBR when the size is a hard constraint.
- Ignoring container overhead. MP4 and MKV add headers, an index and per-frame metadata. It is a fraction of a percent for a long file, but it is never negative — leave a little headroom under a hard cap.
- Comparing bitrates across codecs. 5 Mbps of AV1 and 5 Mbps of H.264 do not look the same. Compare bits per pixel within a codec, and compare codecs by looking at the picture.
- Sizing from the source resolution. Bits per pixel uses the encoded frame size. Downscaling 4K footage to 1080p before encoding changes the quality math completely.
Related calculations and when to use something else
Bitrate planning starts with a frame size, so settle the resolution first: the aspect ratio calculator gives you dimensions that are exact multiples of your delivery ratio and even on both axes, which is what 4:2:0 codecs require. If the target is a specific display rather than a specific ratio, the pixel density calculator tells you when extra resolution stops being visible at the viewing distance.
Downstream, the finished size is a transfer problem and a storage problem. The data transfer time calculator applies protocol efficiency to the upload estimate, the Mbps to MB/s converter settles the bits-versus-bytes question in either direction, and the TB to TiB calculator explains the gap between what the encoder reports and what the file manager shows. For an audio-only deliverable, the audio file size calculator handles sample rate and bit depth for uncompressed formats, which this page does not.
Use a different method when quality rather than size is the constraint. Constant-rate-factor encoding lets the bitrate float to hold a chosen quality level, and no arithmetic predicts the resulting size — you encode a representative sample and measure. Use per-title or per-shot encoding analysis when you are building a streaming ladder at scale, since a fixed bits-per-pixel target wastes bandwidth on easy content and starves hard content.