Internal units
Every quantity is converted to one internal representation at the moment it is entered, and back to a display unit only when it is shown. Nothing is converted in between, and no intermediate value is ever rounded.
- Bitrate is stored in bits per second.
- Capacity and file size are stored in bytes.
- Duration is stored in seconds.
- A percentage is stored as a fraction, so 5 % is
0.05. - A pixel dimension is a whole number of pixels.
One byte is eight bits, exactly and everywhere. There is no other conversion factor anywhere in these tools.
Bitrate units are decimal, always.Kbps is 1 000 bits per second, never 1 024. Mbps is 1e6 andGbps is 1e9 bits per second.
Storage units are decimal by default.KB is 1e3 bytes,MB is 1e6, GB is 1e9, and TB is 1e12. That is what a card or drive manufacturer means by the number printed on the packaging. Binary units are available as an explicit choice and are always labelled with their binary names — KiB is 1 024 bytes, MiB is 1 048 576, GiB is 1 073 741 824, andTiB is 1 099 511 627 776. A value shown asGB is never a binary gibibyte.
Duration units are the ordinary ones: a minute is 60 seconds, an hour 3 600, a day 86 400.
Video file size
Answers how large will this export be? from a duration and a bitrate.
totalBitrateBps = videoBitrateBps + (includeAudio ? audioBitrateBps : 0) payloadBits = totalBitrateBps × durationSeconds payloadBytes = payloadBits / 8 fileSizeBytes = payloadBytes × (1 + overheadFraction)
Container overhead models the non-payload bytes a container adds — index, headers, per-frame structure — as a percentage added to the payload. Its default is 0 %, so the default result is the exact payload size.
Size per minute and size per hour are the same file size divided by the duration expressed in those units.
Video bitrate
Answers what video bitrate fits my size budget? — the inverse of the calculation above.
targetBytes = target size converted to bytes payloadBytes = targetBytes / (1 + overheadFraction) payloadBits = payloadBytes × 8 totalBitrateBps = payloadBits / durationSeconds videoBitrateBps = totalBitrateBps − (includeAudio ? audioBitrateBps : 0)
Note that overhead divides here, where it multiplied above: the target size is what ends up on disk, so the payload that fits inside it is smaller.
If the audio track alone already needs more than the target size, the result is an error rather than a negative or clamped bitrate. A number that cannot happen is not reported as if it could.
Recording time
Answers how long can I record on this card?
usableBytes = capacityBytes × cardCount × (1 − reserveFraction) payloadBytes = usableBytes / (1 + overheadFraction) payloadBits = payloadBytes × 8 totalBitrateBps = videoBitrateBps + (includeAudio ? audioBitrateBps : 0) durationSeconds = payloadBits / totalBitrateBps
Reserve models capacity you do not intend to fill — formatting overhead, a safety margin, or an existing partial fill. Its default is 0 %, so the default answer assumes the card is empty and will be filled completely.
Capacity used per minute is totalBitrateBps × 60 / 8 bytes.
Upload time
Answers how long will this transfer take? The same arithmetic describes a download; the label is a UI string, not a second calculation.
bytesToSend = fileSizeBytes × (1 + overheadFraction) bitsToSend = bytesToSend × 8 effectiveBps = connectionBps × efficiencyFraction durationSeconds = bitsToSend / effectiveBps
Protocol overhead adds to what has to be sent, so it multiplies here. Efficiency models the share of the advertised link speed actually achieved; its default is 100 %, which is the identity value. Any other default would be a measurement this project has not made.
Connection speeds are entered in bits per second by default, because that is how connections are advertised. Byte-based units are offered as an explicit alternative and are converted at eight bits per byte on entry.
The result is always a duration, never an absolute clock time: the calculation reads no clock.
Aspect ratio
Answers what ratio is this, and what are the matching dimensions? in three modes. This calculator involves no bitrate, capacity, or duration.
Dimensions to ratio
wi = round(width); hi = round(height) g = gcd(wi, hi) // Euclidean, on positive integers ratio = (wi / g) : (hi / g) decimal = width / height
A table of known ratios is checked first, in a fixed order: 1:1, 5:4, 4:3, 3:2, 16:10, 16:9, 1.85:1, 2:1, 2.35:1, 2.39:1, 21:9, 4:5, 2:3, 3:4, 9:16, 9:21. If the decimal ratio is within 0.5 % of one of them, that known ratio is the primary answer and the exact reduced ratio is shown beneath it. Otherwise the exact reduced ratio is the answer when both its terms are 50 or less, and the decimal form N.NN:1 is the answer when they are not.
The known-ratio check does not depend on how small the reduced terms are: a 1998 × 1080 frame reduces exactly to 37:20, but the useful answer is 1.85:1.
Ratio and one dimension to the other
heightFromWidth = width × (ratioH / ratioW) widthFromHeight = height × (ratioW / ratioH)
Both the unrounded value and the value rounded to the nearest whole pixel are shown, with a note when they differ. An optional snap rounds to the nearest even integer instead, because many codecs require even dimensions.
Fit a source into a target ratio
sourceRatio = w / h
targetRatio = ratioW / ratioH
contain: sourceRatio > targetRatio → fitW = w, fitH = w / targetRatio (letterbox)
otherwise → fitH = h, fitW = h × targetRatio (pillarbox)
cover: sourceRatio > targetRatio → cropH = h, cropW = h × targetRatio
otherwise → cropW = w, cropH = w / targetRatioAssumptions
These hold for every result on the site, and they are the reason a real export can differ from the number shown.
- The bitrate you supply is treated as the average bitrate actually achieved. Nothing here inspects an encode or predicts one.
- No codec behaviour is modelled. These tools do not estimate how a particular encoder will spend bits, and they do not predict the size of a variable-bitrate encode. Doing so would need empirical encode data this project does not have and will not invent.
- Container overhead defaults to 0 % and transfer efficiency defaults to 100 %. Both are identity values, deliberately: a plausible default such as "3 % overhead" or "80 % efficiency" would silently change every result by an amount this project has not measured. Both fields are exposed, so a number you have measured yourself can be entered.
- Every advanced field's default is its identity value, so leaving the advanced panel closed gives exactly the same answer as opening it and changing nothing.
- Calculator inputs are not stored or transmitted. The arithmetic happens in your browser.
- No platform bitrate recommendation is built in. Platform guidance changes and belongs in a guide with a citation and an access date, not in a formula.
Rounding and display
Rounding happens only when a number is displayed. The calculation itself returns unrounded values, so a result never inherits an error from an intermediate step.
Bitrate
- Below 1e3 bps: a whole number of bits per second.
- Below 1e6 bps: kilobits per second, two decimals.
- Below 1e9 bps: megabits per second, three decimals.
- 1e9 bps and above: gigabits per second, three decimals.
Three decimals on megabits because a bitrate that fits a size budget exactly is only meaningful at that precision. Trailing zeros are kept so a column does not jump width while you type.
Storage
- The automatic unit is the largest one in the active system where the value is at least 1, capped at terabytes. Below one kilobyte, the value is shown in bytes.
- Bytes: no decimals. Kilobytes, megabytes and gigabytes: two. Terabytes: three.
- The exact byte count is always shown as a secondary output, grouped with thousands separators and never rounded.
Duration
- The primary display is
H:MM:SS, with the hour field unpadded and unbounded, and seconds truncated toward zero. - A secondary line gives the unrounded decimal value in the most natural unit: seconds to two decimals below a minute, minutes to four decimals below an hour, then hours, then days to four decimals.
- A human phrase accompanies both, for example
1 h 25 min 13 s.
Everything else
- Percentages: one decimal, with a per-cent sign.
- Ratios: whole numbers when they reduce, otherwise
N.NN:1. - Numbers are formatted for English, grouped in thousands, with a full stop as the decimal separator. No result is ever shown in exponential notation.
Input bounds exist for a numerical reason rather than an arbitrary one: they keep every intermediate bit count below 253, which is the largest integer a double-precision number represents exactly. Within those bounds the intermediate values in the formulas above are exact, and division — which appears once, at the end of each calculation — is the only source of a non-terminating value.
Limits — what these results do not tell you
- They do not predict what your encoder will actually produce. A variable-bitrate encode of a static shot and of a fast-moving one at the same nominal setting produce different files. These tools describe the target, not the outcome.
- They do not tell you what bitrate to use. That depends on the codec, the content, and the destination, and it changes over time.
- They do not model a specific card, drive, or container. Real media has formatting overhead and a real container has structure; both are exposed as fields you can set, not as numbers assumed on your behalf.
- They do not account for a transfer that slows, stalls, or retries.A transfer estimate is a constant-rate division.
- They do not handle frame rates, timecode, or pulldown. Nothing here is frame-based.
- They are not a substitute for a test export. For a delivery that matters, check against your own equipment.