Video File Size Calculator

About this tool

File size is bitrate multiplied by time, but the units are where it goes wrong. Bitrate is bits per second and file size is bytes, so the product has to be divided by eight. Miss that and every answer is eight times off — and eight times does not look like a bug, it looks like an expensive codec. The tool keeps the division in one place so the rest of the arithmetic is about bitrate, not about remembering which side of the slash you are on.

Real recordings are rarely one stream. A typical 1080p clip carries a video track at 8 Mbps or so and one or more audio tracks at 128 to 256 kbps each, and the container adds its own index and track headers on top. That overhead is small but not zero — around one percent for MP4 — and it is the difference between a file that fits on a card and one that stops a few seconds short. Audio tracks are usually negligible next to video, but they are not free, and two commentary tracks are still real bytes.

The last piece is that storage is described with two different rulers. Hard drives, memory cards and cloud plans count a gigabyte as 1000 megabytes. Operating systems and most editing software count a gibibyte as 1024 mebibytes. The same file is therefore about 7.4 percent smaller in the second reading than the first, which is why a card that advertises 64 GB reports about 59.6 GiB. Both numbers are correct; they are answering different questions. This tool shows them side by side so the size you plan against is the one your device will actually display.

Why MB/s is eight times Mbps, not a thousand

MB/s is a byte rate while Mbps is a bit rate, so it is defined here as 8 million bits per second — eight times Mbps. Same-looking prefixes, different quantities: megabyte against megabit.

The unit table has three entries: kbps at a thousand bits per second, Mbps at a million, and MB/s at eight million. The last is the odd one out because it counts bytes — one megabyte per second is eight megabits per second — and that factor of eight lives in the unit rather than being applied later.

It is the same eight that separates bitrate from file size, seen from the other direction. Choosing the wrong one changes the answer by a factor of eight with no error message; the number simply comes out wrong. That is why each unit carries its own factor, instead of relying on the reader to remember which side of the slash they are on.

Why the recording-time estimate subtracts overhead first

The reverse calculation divides the target by 1 plus the overhead percentage before dividing by the bitrate. Applying the bitrate to the raw target would give a longer, wrong answer — and too long is the dangerous direction.

Overhead is added as a percentage of the payload, so it has to be removed as a percentage too. The usable payload is the target divided by one plus the overhead fraction; only then is that turned into seconds at the chosen bitrate. The forward and reverse directions therefore share the same overhead figure rather than using two approximations of it.

Getting this wrong errs toward optimism, which is the worst way to be wrong here. An estimate that says the card holds slightly more than it does leads to running out of space mid-recording; one that says slightly less only costs a few minutes of margin. The forward direction has the same asymmetry, which is why the audio and container shares are itemised rather than lumped into a single number.

How the duration field is read

The string is read from the right, so the last segment is always seconds: 90 means 90 seconds, 01:30 means a minute and a half. Only the seconds may be fractional — minutes and hours must be whole, and 1.5:00 is rejected as ambiguous.

Reading right to left is the same rule as a timecode and lets you drop the leftmost fields: 45 is forty-five seconds, 5:00 is five minutes, 1:05:00 is an hour and five minutes. Minutes must stay under 60 and seconds under 60, so 01:75 is not accepted as an easier way to write 02:15.

The seconds field is the only one allowed a fraction, because durations are often not whole — 90.5 and 01:30.5 are both accepted. Hours and minutes may not be fractional, so 1.5:00 is rejected rather than guessed at: it could mean ninety minutes or an hour and five minutes, and the parser declines to choose.

One display consequence follows from the same design: the clock is formatted without rolling over to days, so a result over 24 hours reads 25:00:00 rather than one day and one hour. For recording-time estimates that is the more useful convention, since the question is usually how many hours remain, not how many days.

kbps, Mbps and MB/s are left untranslated on purpose

These are technical notation, not ordinary words. Rendering them as words loses the case of the b, and the same notation appears untranslated in device manuals in every language. The label therefore stays as written, and the locale explains it.

Two conventions cause most of the trouble: b versus B, a factor of eight, and what the prefix means, where M is ten to the sixth. A 100 Mbps connection therefore delivers about 12.5 MB/s, not 100 MB/s — the provider quotes the first and the download window shows the second.

The same has to hold in parentheses: 8 Mbps equals 1 MB/s. Video bitrates, cloud storage throttles and USB drive ratings each use one of the two systems, so comparing them across systems is out by eight while both numbers look reasonable.

The unit names are therefore treated as data rather than copy: kbps is written kbps in every language. The locale explains that this is bits rather than bytes, but does not rewrite the notation, since rewriting it is what makes it ambiguous.