If you've ever compressed a video, uploaded a clip to Discord, or watched a YouTube video buffer, "bitrate" is the number silently controlling the outcome. It also happens to be the one number that most tutorials name-drop without explaining, which is why "compress this to 25 MB" feels like arcane knowledge instead of arithmetic. It really is just arithmetic - here's the mental model that makes it click.

Picture a garden hose. Bitrate is how much water flows through the hose per second. A thin trickle means a small file but a fuzzy picture; a fire-hydrant blast means a huge file but every detail preserved. The video, from the encoder's perspective, is a river of information that has to squeeze through whatever hose you give it. Give it a thin hose (low bitrate) and it drops details to fit. Give it a thick hose (high bitrate) and it keeps everything. That's it.

#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 how complicated the picture is and you have the visible quality. That's the whole framework.

#The units

Bitrate is measured in bits per second, and you'll see two size suffixes in the wild:

  • kbps (kilobits per second) = 1,000 bits per second. Small numbers use this. Audio ("128 kbps AAC") and very low-resolution video ("500 kbps 480p clip") get stated in kbps.
  • Mbps (megabits per second) = 1,000,000 bits per second, or 1,000 kbps. Bigger numbers use this. Anything at 720p and up is usually stated in Mbps: "5 Mbps 720p", "10 Mbps 1080p", "40 Mbps 4K".

Watch the case carefully - kbps and Mbps (lowercase "b" for bit) are different from KBps and MBps (uppercase "B" for byte). One byte is eight bits, which is why file-size math always divides by 8: your internet plan might advertise "100 Mbps" but that only downloads at 12.5 MB per second, because there are eight bits in every byte. Video bitrates are almost always stated in the lowercase-b, bits-per-second form.

#The file-size formula

The math looks intimidating for one line but it's just multiplication and a divide by 8:

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.

Try it

What a file size buys the picture

Size
443 kbpsfor the picture
  • Video
  • Audio 64 kbps
  • 5% kept in reserve

Pick a size and a length to see the resolution Wave would choose.

For a 1080p, 30 fps source. The figures come from the same code Wave's converter uses when you set a File size, so this is what it would actually do.

#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 20 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 bitrate Wave picks by default depends on the source resolution and frame rate. To aim at a size instead - 16 MB for WhatsApp, about 18 MB for email, 20 MB for Discord, or any number - open Options and set File size: Wave works out the bitrate from the length exactly as above, keeps 5% in reserve, and lowers the resolution when the bitrate would be too thin. See Compress MP4.

#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.