DeviceBenchFree bitrate calculator
Bitrate calculator that counts the bytes both ways
Give it any two of bitrate, recording length and file size and it returns the third, with the audio track added into the total rather than left for later. Every size comes back twice over — in powers of ten, which is what a bitrate and the capacity on a box both mean, and in powers of two, which is what your file manager will show while still writing MB — because that gap is 4.63% at megabyte scale and 6.87% at gigabyte scale and it is where most hand-worked estimates come apart. The one thing it cannot do is predict an encode set to constant quality rather than a bitrate: with no target to multiply, the size depends on how hard the footage is.
- 100% free
- No signup
- Three directions
- MB and MiB side by side
- 11 upload presets
YouTube states a range for 4K — 35 to 45 Mbps at 30 fps and 53 to 68 at 60 — and these take the upper end, so the estimate errs large. Its stereo AAC recommendation is 384 kbps; the Twitch rows use 160.
File size
628.8 MB
(8,000 + 384) kbps × 1000 ÷ 8 × 600 s = 628,800,000 bytes
Two things sit outside this arithmetic. Muxing costs a little more than the tracks add up to — an index, headers and a per-frame structure that comes to well under 1% of a single-track MP4 — and a variable-bitrate encode only averages out to its target, so a two-minute clip can miss by several percent where a two-hour one will not. An encode set to constant quality instead of a bitrate has no target at all, and nothing on this page can predict its size.
How to work out video file size from a bitrate
Pick the missing quantity, set both tracks, then read the size in both unit systems.
Say which of the three you are missing
The switch at the top decides the direction: file size when you know the bitrate and the length, bitrate when you have a size to hit inside a fixed length, and recording length when you want to know how far a card or a drive stretches. Whichever you pick, its input box disappears and the other two stay exactly as you typed them.
Set both bitrates, or take a published target
The video figure is the one your encoder is set to; the audio figure sits underneath it and is added before anything is multiplied, which is the step most people leave out. If you do not have a number in mind, the dropdown holds eleven targets straight from the platforms — eight YouTube rows for H.264 uploads and three for Twitch, whose 6,000 kbps ceiling is a hard limit rather than a suggestion.
Read the size in both unit systems before you trust either
The result panel gives an exact byte count, then that count in powers of ten and in powers of two. The first is what the bitrate, the platform limit and the capacity on the box all mean; the second is what Windows will show you, still spelled MB and GB. When a file looks 7% smaller than you calculated, it is almost always these two lines being compared to each other rather than anything having gone missing.
Technical specifications
| The identity | bytes = (video kbps + audio kbps) × 125 × seconds, where 125 is 1,000 bits divided by 8; rearranged for whichever of the three is missing |
|---|---|
| Every size printed twice | 10⁶ and 10⁹ beside 2²⁰ and 2³⁰ — the same file reads 4.63% smaller in MiB than in MB, and 6.87% smaller in GiB than in GB |
| Audio counted into the total | Added before the multiplication: 384 kbps on an 8,000 kbps video adds 4.8% to the file, 128 kbps on a 1,000 kbps one adds 12.8% |
| Upload targets built in | 11 presets — eight YouTube SDR H.264 rows from 720p30 to 2160p60 and three Twitch rows up to its 6,000 kbps ceiling |
| Live upload figure | Total bitrate × 1.2, sustained; Twitch 1080p60 with 160 kbps audio comes to 6,160 kbps and asks for 7.39 Mbps |
| Deliberately excluded | Container overhead, which is under 1% of a single-track MP4, and any constant-quality encode, which has no bitrate target to multiply |
| Accepted input | Video 0-500,000 kbps, audio 0-5,000 kbps, lengths up to 100 hours, sizes up to 10 TB entered as MB, GB, MiB or GiB |
| Where the arithmetic runs | In this tab — no bitrate, size or preset is transmitted, and nothing is restored on a later visit |
Frequently asked questions
The file on my drive is smaller than this calculator predicted. Where did the rest go?
Almost certainly nowhere — you are reading a number in a different unit system. A file manager on Windows divides by 1,048,576 to get megabytes and by 1,073,741,824 to get gigabytes, then labels the result MB and GB anyway, so a recording of 628,800,000 bytes appears as 599.67 rather than 628.8. That is the same file, 4.63% smaller-looking at megabyte scale and 6.87% at gigabyte scale, which is also why a drive sold as 1 TB shows up as 931 GB. Both columns are printed here so the comparison takes a second instead of an afternoon.
Is a megabit the same as a megabyte?
No — a byte is eight bits, so they differ by a factor of eight, and video is the one place both units appear within a single sentence. Bitrates are quoted in bits per second: 8,000 kbps is 8 megabits per second, which moves 1,000,000 bytes each second. Internet plans are sold in the same bit units, which is why a 100 Mbps connection tops out around 12.5 MB/s in a download manager. Getting the eight backwards is the fastest way to be wrong by 64 times in either direction.
Does the audio track really change the file size much?
It changes it by whatever fraction of the total it is, which is small at high video bitrates and far from small at low ones. A 384 kbps stereo AAC track on top of an 8,000 kbps 1080p video adds 4.8% — 28.8 MB on a ten-minute recording — while the same track on a 1,000 kbps 360p upload would add more than a third. The reason it is worth including at all is that most people are working near the low end when they are counting bytes, and an estimate that quietly drops it always comes in light rather than heavy.
My export came out well under the size this predicts. Is the calculator wrong?
The calculator is exact for constant bitrate and an estimate for everything else, and most encoders are not running constant bitrate. A variable-bitrate encode spends less on still footage and more on motion, so it hits its average over a long file and can miss by several percent on a short one. A constant-quality encode — x264's CRF, NVENC's CQ — has no bitrate target at all: you are asking for a quality level and the size falls out of how hard the footage is, which is why a talking head and a confetti cannon at the same CRF differ by a factor of five.
What bitrate should I actually use for 1080p at 60 fps?
YouTube asks for 12,000 kbps of H.264 for SDR 1080p60, and 8,000 for the same footage at 30 fps — so 60 fps costs about half as much again, not double, because consecutive frames at a higher rate resemble each other more and compress better. Newer codecs need less for the same look: HEVC and AV1 typically land around two thirds of the H.264 figure, and YouTube re-encodes everything on arrival regardless, so an upload above the recommendation buys quality through the transcode rather than on the page. Twitch is a different problem entirely, since 6,000 kbps is the ceiling and the bitrate has to be chosen to fit under it.
How much upload speed do I need to stream at 6,000 kbps?
More than 6 Mbps, and the panel prints the figure: total bitrate plus 20%, sustained, which for Twitch at 1080p60 with a 160 kbps audio track means 7.39 Mbps of headroom on the link. The margin is not padding — retransmits, other devices on the connection and the difference between a peak reading on a speed test and a rate the line can hold for three hours all live in it. Check the upload figure rather than the download one, since consumer connections are usually asymmetric by a factor of ten or more.
Why does it forget my settings between visits?
Because nothing you type here is written down anywhere. The bitrates, the length and the size feed a couple of multiplications inside this tab and are gone when it closes, so the form comes back on its defaults rather than on the project you were pricing last week. If a result matters, the copy button puts the whole working — inputs, byte count, both unit systems — on your clipboard as plain text.
About bitrate, the factor of eight, and the two kinds of megabyte
A bitrate is a promise about a second: it is how many bits of encoded video and audio come out of the encoder for every second of footage, so multiplying it by a duration gives the total number of bits, and dividing that by eight gives bytes. Everything else in this area is bookkeeping around those two steps. The bookkeeping matters because the two halves of the sentence are quoted in different units by convention — encoders, platforms and internet plans all speak in bits per second, while drives, file managers and upload limits all speak in bytes — and the factor of eight sits silently between them. It is why 8,000 kbps sounds like a big number and produces a 1 MB/s stream, and why a connection sold as 100 Mbps never downloads faster than about 12.5 MB/s no matter what is at the other end. Container overhead is genuinely a rounding error next to this: the index and headers of a single-track MP4 come to well under one percent, and they are excluded here rather than guessed at.
The second trap is older and has a standards body attached to it. Computers address memory in powers of two, so kilobyte came to mean 1,024 bytes in some contexts and 1,000 in others; IEC published the unambiguous binary prefixes — kibi, mebi, gibi, with the symbols KiB, MiB and GiB — in 1998, and adoption has been partial ever since. Storage manufacturers count in powers of ten, which is why a 1 TB drive genuinely contains a trillion bytes. Windows Explorer counts in powers of two and prints the decimal abbreviation on top of it, which is why that same drive appears as 931 GB and why users have been suspecting manufacturers of shortchanging them for thirty years. Apple settled the argument on its own platforms in 2009 by switching the Finder to powers of ten, so an identical file can legitimately read 4.63% larger on a Mac than on a PC at megabyte scale. This calculator refuses to pick a side: it prints the raw byte count, then both conversions, and lets you match whichever number you are comparing against.
Choosing the bitrate in the first place is a judgment about the footage rather than a calculation, but three regularities help. Resolution matters less than people expect and motion matters more — a static screen share at 1080p compresses to a fraction of what a first-person shooter needs at 720p. Frame rate costs roughly half again rather than double, which is why YouTube asks 12,000 kbps for 1080p60 against 8,000 for 1080p30; the Hz to ms converter is the other side of that decision, since the frame rate you capture at is also a budget the machine has to hit. And the codec sets the floor: HEVC and AV1 typically need about two thirds of the H.264 figure for the same appearance, at the cost of encoding time. When the recording itself stutters rather than merely weighing too much, the bottleneck is upstream of all of this — the FPS test shows whether the frames existed to be captured, the bottleneck calculator weighs the processor against the graphics card that is also running the encoder, and the PSU calculator adds up what a machine encoding and gaming at once actually draws. If you are not certain what resolution the capture is running at to begin with, the device info page reports what this machine believes about its own display and processor.
Where these numbers are worked out
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
No video is involved at any point — this page never sees a file, only the handful of numbers describing one, and those are multiplied in the tab and discarded with it. Nothing is written to storage, which is why every field returns to its default the next time you open the page.