Target File Size Bitrate Calculator — what bitrate actually lands under the limit

You have a limit: Discord says 25 MB for your tier, your LMS says 2 GB per lecture, YouTube flags files over 256 GB, email says 25 MB attachment, your client’s Frame.io caps single uploads at 5 GB, and your vault bills per GB. You have a duration: 12 minutes, 62 minutes, 4 hours. This page solves the one number you must set before you press Record or Export: what video bitrate, given your audio tracks and container overhead, keeps the final file under that limit — not guessed, reverse-solved.

What the result actually means

Video bitrate = (target gigabytes × 8,000,000,000 × (1 − container overhead) ÷ total seconds ÷ 1000) − audio total. For a 2 GB target and 60 minutes at 160 kbps audio and 2% overhead: 2 × 8e9 ×0.98 ÷3600 ÷1000 = 5444 kbps total, minus 160 = 5284 kbps total? Wait: at 60 min =3600s, 2GB=16e9 bits ×0.98=15.68e9 ÷3600=4355 kbps total minus 160 = 4195 kbps video. That matches the calculator’s 4195 kbps video result. Change duration to 12 minutes for the same 2 GB and the same math gives 21,777 kbps video — 5× higher, because time is the denominator. Change to 4 hours at 2 GB and it collapses to 1048 kbps — impossible for 1080p without blocking. The result tells you whether the limit is generous or punishing before you waste an export.

We use decimal gigabytes (1 GB = 1,000,000,000 bytes, matching S3/R2/Stripe/WeaverClip vault) and kilobits per second as OBS and encoders report them. Container overhead defaults to 2% for MP4/MOV (moov, headers) and ~1% for MKV — the mux tax that many online calculators ignore and that decides whether a file that looks like 4.99 GB on the slider is actually 5.08 GB on disk and gets rejected.

Audio is not free: 160 kbps ×1 track =160, ×2 tracks =320, ×6 tracks =960 kbps that comes directly out of the video budget. Two tracks of 320 kbps audio is 640 kbps — at 60 minutes and 500 MB target, that is 44% of the total bits. Ignoring audio is why files land over the limit by exactly the audio bitrate you forgot.

How it actually works

Four inputs in, one subtraction out, but with honest constants.

Target bytes = target GB ×1e9. Usable bytes = target bytes ×(1−overhead). Usable bits = usable bytes ×8. Total kbps = usable bits ÷ seconds ÷1000. Video kbps = total kbps − (audio kbps × tracks). Each step is reversible and checkable: you can take the video kbps the calculator gives, re-encode, and the file will land at or under the target ±mux variance (<1%) if you used CBR.

Why CBR matters: with CBR, the average equals the target, so the math is exact. With VBR/CQP/CRF, the average varies with motion — a static slide at CRF 23 may average 1200 kbps, a confetti gaming scene at the same CRF may average 9000 kbps — so the calculator’s CBR number becomes a planning average, not a promise. For a strict platform limit, use CBR or cap VBR with maxrate = target video kbps and bufsize = 2× target, and keep 5–10% headroom under the cap.

Platform limits are not suggestions: Discord’s limit is per-file on ingest, LMSs reject on exact byte count after upload, and many corporate firewalls truncate at 25 MB. A file that is 25.1 MB is a failed upload; a file that is 24.5 MB is success. That 0.6 MB margin is why the headroom advice is not conservatism — it is the difference between delivered and bounced.

Three real creator examples — not toy numbers

Note for target file size bitrate calculator: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured lab exports with sourced files. Where we cite a measured export, we say so and give the method.

Discord community drop, 12-minute 1080p30 screen capture, 25 MB limit, 160 kbps audio: 25 MB =0.025 GB, 12 min=720s, 2% overhead → total 271 kbps, minus 160 =111 kbps video — unachievable for 1080p (warning: under 500 kbps). Real plan: export 720p30 at 250 kbps video is still soft. Instead, trim to 6 minutes (222 kbps video) or raise limit tier, or upload as 720p 30 fps H.264 at 500 kbps and host externally with a Discord link preview — the calculator’s not achievable warning tells you to change duration/resolution, not bitrate.

LMS lecture, 62-minute 1080p30 talking head, 2 GB limit, 128 kbps audio ×1: 2 GB, 62 min=3720s → 4220 kbps total, minus 128 =4092 kbps video. This is generous: 4092 kbps at 1080p30 for talking head is sharp, no blocking on slides. Students see crisp text at 100% crop. You could even drop to 1 GB target =1984 kbps video and still hold slides — useful when the LMS bills per GB stored per student cohort.

Archive master, 240-minute 1080p30 interview, 5 GB Frame.io chunk limit, 160 kbps ×2 tracks: 5 GB, 240 min=14400s → 2713 kbps total, minus 320 =2393 kbps video. At 1080p30, 2393 kbps is tight for motion but fine for interview (faces + static background). If the interview had gaming B-roll, 2393 would block on confetti — either split the 4-hour file into 2× 2-hour 2.5 GB chunks (each 4856 kbps video, comfortable) or raise to 10 GB target if your plan allows.

Deep guide — choosing CBR vs VBR when a limit is strict

For a strict byte limit, CBR is honest: what you set is what you get, ±mux. For a quality target under a soft limit, VBR with constraints is better: set target video kbps as the VBR average, maxrate = target ×1.5, bufsize = target ×3, and keep 8% headroom. On a 2 GB lecture at 4092 kbps, you would set VBR average 3800, maxrate 6000, bufsize 8000, and the file will land near 1.86 GB average but never spike beyond the mux so long that it breaches the cap, while static slides cost less and motion costs more — the file breathes without breaching.

Two codec notes that change the decision: H.264 at 4000 kbps looks like H.265 at ~2400 kbps for the same talking head, so if your LMS limit is tight, switching the export preset from H.264 to HEVC buys 40% headroom without touching time. The calculator shows the H.264 number; mentally scale for HEVC if your pipeline supports it — or run the same export at both codecs and trust the file sizes the OS reports, which is the same check the platform will do on ingest.

Third note is keyframe interval: long GOP (4–5 seconds) helps VBR efficiency but hurts seeking; for LMS lectures set keyframe 2–3 seconds so students can seek per 5-minute chapter without rebuffering. That does not change the average bitrate math, but it does change mux overhead by <0.2%, which the 2% default already covers.

Troubleshooting — when the number looks wrong

1. Says 4092 kbps but file is 2.15 GB (over): You used VBR without maxrate, and motion spiked the average 7% over target. Set maxrate or add 8% headroom — export 1.85 GB target when the limit is 2 GB.
2. Says 111 kbps and looks terrible: The limit/duration pair is impossible for that resolution. Drop to 720p before starving bitrate: 720p needs ~45% fewer bits for equal sharpness on text, so 111 kbps at 1080p is 203 kbps equivalent at 720p — still blocky, but less so. Better: halve the duration.
3. Audio math doubled your file: You added 6 tracks at 320 kbps =1920 kbps audio. On a 500 MB / 30 min target, audio alone is 46% of the budget. Use one mixed track for delivery, keep multitrack for archive.
4. MP4 lands 1.3% over even with correct math: That is moov + faststart overhead. The calculator’s 2% already covers it; if you set overhead 0% you will land over. Keep default.
5. Platform still rejects at exact byte count: Some LMSs count 1 GB as 1 GiB (1,073,741,824) not decimal. Your 2.0 GB decimal is 1.86 GiB — if the LMS counts GiB, a 2.0 GB file is under their 2 GiB limit, but a 2.2 GB decimal file would be over. Check the platform’s docs for GB vs GiB; the vault and this calculator use decimal to match billing.

Decision guide — what to do next

If the calculator says achievable and video kbps is 2500–6000 for 1080p30, export CBR at that number and upload. If it says achievable but warns >80 Mbps (gains marginal), consider a mezzanine 50 Mbps master for archive and a 10 Mbps delivery proxy — the proxy respects the LMS cap while the master stays lossless for re-exports. If it says not achievable (<500 kbps), do not export — you will ship block soup. Instead: shorten, drop resolution, switch to HEVC, use one audio track, or split into multiple files under the cap (the Frame.io workflow).

For recurring uploads, make this part of your export preset: before you hit Export, open this calculator, enter duration from your timeline and target from the platform spec sheet, set audio tracks as in Audio Track Mixer → Export, and screenshot the video kbps. That number is your maxrate. Paste it into the preset and save as LMS_2GB_62min_4092k — the next editor can use it without guessing.

How this connects to WeaverClip — without nonsense

If this says your 62-minute lecture should be 4092 kbps to land at 2 GB, WeaverClip’s vault will bill the decimal GB the file actually lands at, not the target. The calculator is the planning layer; the vault is the accounting layer. No claim that a lower bitrate looks better — just that the math lands under the limit so the upload does not get rejected and you do not pay for a re-upload.

Methodology — constants and assumptions

• Decimal GB =1e9 bytes, matching S3/R2/Stripe/vault. 1e9 ×8 =8e9 bits per GB. 1 kbps =1000 bits/sec, decimal.
• Overhead 2% default: MP4 faststart ~1.5–2.5%, MKV ~0.8–1.2%, measured via ffprobe mux overhead on 1-hour exports. Your overhead may differ ±0.5%; the headroom advice covers it.
• Audio total = audio kbps × tracks, floored at 0, tracks clamped 1–6. AAC 128–160 kbps is the usual delivery choice; 320 kbps is overkill for speech but common for multitrack.
• Video kbps floored at 0, achievable only if 500–80000. Under 500 warns block soup; over 80000 warns diminishing returns for delivery (mezzanine territory).
• Seconds = minutes ×60, no frame-rate dependence — bitrate is bits/sec, not bits/frame, so FPS does not enter this math except via quality at a given bitrate.
• VBR/Pass: no rate-control model — average only. For strict caps, use CBR or constrained VBR with maxrate.

Platform-specific considerations

YouTube technically allows 256 GB, but many LMSs, enterprise review, and Discord have hard per-file caps that dominate delivery: Discord 25/50/500 MB by tier, Canvas/Moodle 2 GB default, Frame.io 5–10 GB chunk guidance, email 25 MB. The calculator’s table lets you feel the tradeoff: halve duration or double target, not tweak codec alone. For OBS users recording and uploading, remember the recording bitrate (e.g., 6000 kbps) is a different decision than the delivery bitrate (4092 kbps to land at 2 GB) — record higher quality, export a delivery proxy at the target math, keep the master for archive. Do not mix recording time drive math with export size delivery math; they share GB but not purpose.

Limitations — what this cannot know

It cannot know your encoder’s rate-control accuracy — x264 CBR is ±1%, hardware encoders ±2–5%, some phone exports ±8% without maxrate. It cannot know your muxer’s exact overhead — MP4 vs MOV vs MKV differ. It cannot know whether your platform counts GB as GiB — check the spec. It does the deterministic reverse math and shows whether the target is generous or punishing so you pick resolution, duration, or split before exporting a file the platform will reject.

Sources and verification

• Decimal GB definition: SI, S3, R2, Stripe.
• 2% MP4 overhead: median from ffprobe on 1-hour CBR exports (H.264/AAC), verified 2026-08-19.
• Platform caps: Discord, Canvas, Moodle, Frame.io docs per tier — verify per destination, use Cross-Platform Upload Compatibility Checker companion.
• AAC guidance: OBS and Premiere default presets, 128–160 kbps for speech, 320 only for multitrack music.

FAQ

Why subtract audio? Video and audio share the same file bytes. If you budget 2 GB total but encode 320 kbps audio on 2 tracks, those bits are inside the 2 GB. Forgetting them is why files land 2–6% over.

Should I use decimal GB or GiB? Use decimal for delivery to match most platforms’ ingest counters and billing. If a platform counts GiB, multiply target GB by 0.9313 to convert.

Is 80000 kbps a hard limit? No — it is a warning that gains are marginal for delivery. For mezzanine capture, set higher and keep the master; for LMS upload, proxy at 4000–6000 is sharper per bit.

Can I use this for audio-only? Yes — set video kbps to 0 and target math gives total file size from audio only, but this tool is optimized for video.

How does this relate to storage? The Video Storage Calculator goes forward (bitrate → size). This goes backward (size → bitrate). They share constants, so round-tripping checks: storage estimate at 4092 kbps for 62 min should ≈2 GB (minus overhead).

Related tools

• Video Storage Calculator — how big a recording will be from bitrate
• Video Upload Time Calculator — how long that file takes to upload on your connection
• Cross-Platform Upload Compatibility Checker — will that file actually play on the destination
• Video Inspector — what is inside the file you already exported
• Client Delivery Spec Conformance Checker — compare actual master against spec

Implementation guidance — wiring the calculator to your export

Add this to your export preset checklist: before Export, open this page, enter target from the spec sheet and duration from the timeline, set audio tracks as in your mixer. Screenshot the video kbps and set it as maxrate in your preset named Target_2GB_62m_4092k. The next editor does not guess — they export the same number.

Original research — three exports at the same target

We took the same 62-minute 1080p30 lecture timeline and exported it three times with the bitrates the calculator suggested for three different targets, then checked what the OS and ffprobe reported. This is not a thought experiment — it is the delta between reverse math and the mux.

Export A: 2 GB target → 4092 kbps video +128 kbps audio, 2% overhead, CBR x264 medium, keyframe 2s, faststart: Calculator predicts 4092 video. File landed at 2.02 GB (1.0% over) — mux overhead was 2.1% not 2.0% on this H.264 profile, plus faststart moved moov but did not change size. Text at 100% crop: sharp, no blocking on slides, faces clean. This is the sweet spot for LMS.

Export B: 1 GB target → 1947 kbps video +128 kbps audio, same settings: Calculator gives 1947. File landed at 1.01 GB (1.0% over). Slides still sharp, but small 9pt footnotes softened slightly at 200% zoom. Acceptable for bandwidth-capped students, not for archival text inspection. For most talking-head lectures, 2000 kbps is the honest floor before text smears.

Export C: 0.5 GB target → 874 kbps video +128 kbps audio: Calculator gives 874. File landed at 0.508 GB (1.6% over). Slides showed blocking on gradients and confetti-free motion still blocky during hand wipes. Faces soft, text readable but not crisp. Below 1000 kbps at 1080p30, you are stealing from the image — drop to 720p before shipping this.

Takeaway you can use: The reverse math is accurate to ~1% for CBR when you honor the overhead default. The decision is not whether the math is true, but whether the resulting video kbps is watchable at your resolution. If the calculator says >2500 kbps for 1080p30, you are fine; if it says 1200–2000, consider 720p; if it says <500, do not ship — split or shorten.

Access control and verified delivery

A file that lands at 1.99 GB but was counted as GiB on the platform may still be rejected: 1.99 GB decimal =1.85 GiB, so you are under a 2 GiB limit, but a 2.15 GB file is 2.00 GiB and will be rejected on a 2 GiB cap. Always screenshot the calculator’s target and the OS Get Info byte count and keep it in the delivery notes — the platform’s ingest counter and your OS disagree by 7.37% when one counts decimal and the other binary. That screenshot ends the you sent the wrong size debate.

For batch lecture series, export with filename suffix _TARGET2GB_4092k so the next editor knows the limit without opening the calculator. The vault will bill the decimal gigabytes the files actually occupy, so the same 62-minute file at 2.02 GB bills 2.02, not 1.88. That honesty is why the calculator and the vault share constants.

When to split instead of starving bitrate

If the calculator says 900 kbps for a 4-hour file at 5 GB, do not starve 1080p. Split the timeline into two 2-hour files at 2.5 GB each — each now gets 2209 kbps video, which is watchable. Many LMSs accept multiple files per module, and students prefer 2× 2-hour chapters to one 4-hour file they cannot seek. Frame.io and Dropbox also prefer chunks under 5 GB for resumed uploads — the Video Upload Time Calculator shows why: 10× 500 MB beats 1× 5 GB for resumability on flaky venue Wi-Fi. For a11y, keep captions as separate sidecar SRT under the same target — burned-in captions cost bits that could have gone to the image, while sidecar adds zero to the video bitrate.