Turning a Target File Size Into an Encoder Bitrate
A delivery spec almost never tells you what to type into an encoder. It says the finished file must come in under 250 MB, or fit an upload form, or sit inside a client's asset budget. The encoder, meanwhile, has one field that governs size, and that field is measured in bits per second. Getting from one to the other starts with a single multiplication.
This page handles that step: it takes the megabytes of a size target and restates them as the megabits the encoder thinks in. Divide that by the running time and you have the average bitrate the whole file — picture and sound together — is allowed to hold.
Mb = MB × 8. Worked example: a 100 MB ceiling on a 60-second clip is 800 Mb, and 800 Mb ÷ 60 s gives a total budget of about 13.33 Mbps — from which the audio track still has to be paid.Three Numbers That Decide the Export
The encoder speaks bits per second
-b:v on a command line, the value is a rate in bits per second, usually written as kbps or Mbps. Nothing in that field is expressed in bytes.The deliverable is specified in bytes
Audio takes a slice first
Sizing an Encode With the Converter
Enter the size the finished file must not exceed
Put the megabyte ceiling from the spec into the left field, already set to MB. It accepts a comma or a dot as the decimal separator, so a target written as 249,5 works exactly like 249.5, and stray spaces are ignored.
Read the megabits, then divide by the running time
The right-hand field updates live. Divide that megabit figure by the clip length in seconds and you have the total average rate in Mbps — the ceiling the video and audio streams share between them.
Copy the bare figure into your encode command
Each field has a copy button that puts the plain number on the clipboard with no unit attached, which is what a command-line flag or a preset field wants. Pressing Ctrl+C inside a field does the same thing.
Reverse it to predict a file size
Both boxes are editable, so a megabit total worked out from a bitrate and a duration can be typed on the right to read back the megabytes it will produce. The swap button flips the pair, and the searchable dropdowns reach Kb for an audio-only budget, Gb for a long-form master, or the per-second units when a spec mixes rate and volume.
Target File Size, Clip Length and the Bitrate It Demands
Each cell below is the total average rate that fits the row's file size into the column's duration: megabytes multiplied by 8, then divided by the seconds. Treat every figure as the combined video-plus-audio budget.
| Target size | 30 seconds | 1 minute | 5 minutes | 10 minutes |
|---|---|---|---|---|
| 50 MB | 13.33 Mbps | 6.67 Mbps | 1.33 Mbps | 0.67 Mbps |
| 100 MB | 26.67 Mbps | 13.33 Mbps | 2.67 Mbps | 1.33 Mbps |
| 250 MB | 66.67 Mbps | 33.33 Mbps | 6.67 Mbps | 3.33 Mbps |
| 500 MB | 133.33 Mbps | 66.67 Mbps | 13.33 Mbps | 6.67 Mbps |
| 1 000 MB | 266.67 Mbps | 133.33 Mbps | 26.67 Mbps | 13.33 Mbps |
| 2 000 MB | 533.33 Mbps | 266.67 Mbps | 53.33 Mbps | 26.67 Mbps |
Line the table up against published upload guidance and the trade-offs become obvious. YouTube's suggested figure for 1080p at 24–30 fps is about 8 Mbps, so ten minutes of it lands near 600 MB — a 250 MB ceiling on the same length forces you down to 3.33 Mbps, well into visible-artefact territory on anything with motion. At 4K the recommendation climbs to roughly 35–45 Mbps for 24–30 fps, which means ten minutes wants something like 3 GB and no megabyte-scale ceiling will hold it without a resolution change.
Work from the spec or from the settings
Size on the left when a brief hands you a ceiling, bits on the right when you already have a bitrate and want the file size it implies. Both directions run live as you type.
Clipboard output an encoder flag accepts
Copying a result gives you the raw number without a unit or thousands separator, so it pastes straight into a preset field or a command line without editing.
Kilobit scale for the audio track
The searchable unit lists include kilobits alongside megabits, which is the scale a 128 or 192 kbps audio budget actually lives at when you subtract it from the total.
Readable from clip to feature length
Results carry up to eight decimals with a space between thousands, and switch to exponent form at extreme magnitudes, so a six-second bumper and a two-hour master both stay legible.
Encoding Bitrate Questions
My export landed a few percent over the size I targeted — where did the extra megabytes come from?
Three places, usually. The container adds its own weight: an MP4 carries a header atom describing every frame's position, and that index grows with the frame count. The audio stream is often not included in the bitrate you set, so it is added on top rather than taken out. And a rate-controlled encode targets an average, which it can overshoot on a difficult final scene with nothing left to claw it back from. Budget three to five percent of headroom and set the target slightly under the real ceiling.
Should the video bitrate be the full figure this conversion produces?
No — what you calculated is the budget for everything in the file. Take the audio out first. A 100 MB, 60-second target gives 13.33 Mbps total; a 192 kbps stereo AAC track is 0.192 Mbps of that, leaving roughly 13.14 Mbps for the picture. At short durations the audio share is trivial, but on a ten-minute clip with a 100 MB ceiling the total is only 1.33 Mbps, and letting 0.192 Mbps of it disappear unaccounted for is a real 14% error in the video budget.
Does two-pass encoding actually land on the file size I ask for?
Much more reliably than a single pass. The first pass analyses the whole clip for motion and complexity without writing a final stream; the second then distributes bits against that map, spending them on the hard scenes and saving them on the static ones while holding the average you requested. Because the encoder knows what is coming, the finished size normally lands within a couple of percent of the target. What will not hit a size at all is a pure quality-based mode such as constant-rate-factor encoding, which holds quality steady and lets the size fall where it may.
Is constant bitrate the safer way to hit a hard size ceiling?
It is the most predictable, and that is a genuine virtue when the delivery path cannot tolerate surprises. A constant rate spends the same bits every second, so the size is arithmetic and nothing else. The cost is that a locked-off static shot burns exactly as many bits as a handheld chase. Variable bitrate with the same average and a sensible maximum ceiling gives visibly better quality for the same finished size, so unless a platform demands constant-rate delivery, use the converted figure as a two-pass average and cap the peaks instead.
How do platform recommended upload bitrates fit a file-size budget?
They pull in the opposite direction, and knowingly so. A recommendation such as 8 Mbps for 1080p at 24–30 fps, 12 Mbps at 48–60 fps, or 35–45 Mbps for 4K exists because the platform re-encodes whatever you send and wants a clean source to work from. Compression artefacts in your upload survive that second pass and get worse. So when your file-size ceiling is a hosting or attachment limit, honour it; when the destination transcodes anyway, feed it the higher rate and let the size be whatever it is — encoders punish a starved source far more than a generous one.
No comments yet. Be the first to comment!