Every practical question about video compression - "how do I fit this in 25 MB", "why does my Discord upload look terrible", "what's a good YouTube upload bitrate" - is really a question about bitrate. Once you have a working mental model of what bitrate actually is, the answers become arithmetic.

#The one-sentence version

Bitrate is how many bits per second the video takes up. Multiply it by duration and you have the file size. Divide it by content complexity and you have the perceived quality. That's the whole framework.

#The units

Bitrate is measured in bits per second. In practice you see:

  • kbps (kilobits per second) - 1,000 bits per second. Audio bitrates and low-resolution video are usually stated in kbps: 128 kbps AAC audio, 500 kbps 480p video.
  • Mbps (megabits per second) - 1,000,000 bits per second, or 1,000 kbps. Video bitrates for 720p and higher are usually stated in Mbps: 5 Mbps 720p, 10 Mbps 1080p, 40 Mbps 4K.

Not to be confused with bytes per second - 8 bits equal 1 byte, so 8 Mbps = 1 MB per second (roughly). This ratio is why file-size math always includes a "divide by 8".

#The file-size formula

The simple math:

File size (bytes) = bitrate (bits per second) × duration (seconds) ÷ 8

Example: a 5-minute clip encoded at 6 Mbps for video plus 128 kbps for audio has:

  • Total bitrate: 6,000,000 + 128,000 = 6,128,000 bits per second
  • Duration: 5 × 60 = 300 seconds
  • Bytes: 6,128,000 × 300 ÷ 8 = 229,800,000 bytes ≈ 219 MB

Reversing the math gives target-size compression: if you need a 5-minute clip to fit in 25 MB, you have 25 × 1024 × 1024 × 8 ÷ 300 = 698,300 bits per second total, minus 128 kbps audio = 570 kbps for video. That's a specific number the encoder can hit.

#Rule-of-thumb bitrates by resolution

For H.264 at visually-transparent quality (no obvious compression artefacts on typical content):

  • 360p: 500 kbps - 1 Mbps
  • 480p: 1 - 2 Mbps
  • 720p: 2.5 - 5 Mbps
  • 1080p: 5 - 10 Mbps
  • 1080p60: 8 - 15 Mbps (higher because 60 fps is more frames to encode)
  • 4K: 20 - 40 Mbps
  • 4K60: 40 - 80 Mbps
  • 4K HDR: 60 - 100+ Mbps

For HEVC (H.265), roughly 40% lower for equivalent quality - so 720p HEVC is fine at 1.5 - 3 Mbps, 1080p HEVC at 3 - 6 Mbps, 4K HEVC at 12 - 25 Mbps. See H.264 vs H.265 for why HEVC compresses better.

These are guidelines. Complex content (fast motion, high detail, film grain) needs more bitrate at the same resolution. Simple content (static scenes, cartoons, screen recordings) needs less. See Why video files are so big for the physics behind these numbers.

#Encoding modes: CRF, CBR, VBR

Encoders have different modes for controlling bitrate:

  • CRF (Constant Rate Factor): "Encode at this quality; use whatever bitrate is needed." A value from 0 (lossless, huge) to 51 (worst, tiny); 18-28 is the practical band for H.264. This is the default for quality-first workflows. File size is unpredictable - a simple 5-minute talking-head clip and a 5-minute action scene at the same CRF produce very different file sizes.
  • CBR (Constant Bit Rate): "Encode at exactly this bitrate, every second." Predictable file size (bitrate × duration = size), but wasteful for simple content (uses the full bitrate even when the frames don't need it) and lossy for complex content (can't exceed the bitrate even when a scene demands more bits). Used for streaming where bandwidth is fixed.
  • VBR (Variable Bit Rate): "Aim for this average bitrate, but spend more on complex scenes and less on simple ones." Best quality-per-bit trade-off. Two-pass VBR (encode once to analyse, encode again to distribute bits) hits a target file size within 1-2% while smart-allocating the bits.

Which mode when

  • Editing intermediate / archival: CRF at a high-quality value (18-20). File size is whatever it is; quality comes first.
  • YouTube upload / archival with size headroom: CRF 20-22.
  • Fit in a specific size (Discord tier, email attachment): Two-pass VBR with the calculated bitrate.
  • Streaming, live delivery: CBR (bandwidth-fixed) or capped VBR (bandwidth-limited with quality flexibility).

#Common bitrate mistakes

  • Uploading source-quality to a re-compressing platform. WhatsApp, Instagram, and (to a lesser extent) TikTok all re-compress uploads server-side. A 6 Mbps 1080p upload gets stacked with a second aggressive compression pass at their target bitrate; the resulting quality is worse than pre-compressing to their target yourself.
  • Encoding at higher bitrate than the source. Re-encoding at a higher bitrate than the source doesn't restore quality - it just makes a larger file with the same visible loss. Bitrate is a ceiling on quality, not a floor.
  • Missing the audio bitrate in the math. Audio adds 96-192 kbps to your file. Ignoring it makes your target-size math undershoot by a percent or two, which matters at tight caps like Discord's 25 MB free tier.
  • Using CBR for archival. Wastes bitrate on simple content and starves complex content. Use CRF or VBR instead.

#Bitrate on Wave's outputs

Wave's MP4 output uses the browser's WebCodecs encoder (see What is WebCodecs?) at a quality-per-resolution curve tuned for visually-transparent output. The specific bitrate Wave picks depends on the source resolution and frame rate; it's not currently user-configurable in the UI. For target-size compression (fit under Discord 25 MB, WhatsApp 16 MB, email 25 MB), Wave's compression pages give you the math to run the encode with HandBrake or ffmpeg locally at your specific target.

#The takeaway

Bitrate is bits per second. Multiply by duration for file size; divide by content complexity for quality. Use CRF for quality-first workflows, VBR two-pass for target-size, CBR only for streaming. Don't re-encode at higher bitrate than the source, don't forget audio in the math, and don't upload source quality to platforms that re-compress. Everything else is finding the right bitrate for your specific case.