What Bitrate Controls

Set FileFlip's Bitrate control to 1 Mbps and a 10-second clip comes out within about 2% of what the arithmetic predicts, whichever resolution you picked. What that 2% buys you is a different story: the same 1 Mbps, measured on our own encodes, landed anywhere from VMAF 62 to 68 depending only on the resolution the encoder had to fill.

Should you raise the bitrate or lower it?

Lower it when:

• The file has to clear a hard limit: an email attachment, a form upload, a plan's storage cap.
• You're sending it somewhere the connection is the bottleneck, not the screen it'll play on.
• Convert MOV to MP4 and set Bitrate under Advanced options to FileFlip's lowest preset, 1 Mbps, then work up from there if the picture looks rough.

Raise it when:

• You'll edit the file again later and don't want to start from something already thin.
• The source has real motion or fine detail, grass, water, a crowd, the kind of picture that costs more bits to hold onto at any setting.
• Convert WAV to MP3 and leave Bitrate at 320 kbps if you'd rather not think about audio quality again.

Bitrate at a glance

The arithmetic, done once

File size is bitrate times duration, divided by eight to turn bits into bytes. A 5 Mbps video running 10 seconds with a 96 kbps audio track should land at (5,096,000 × 10) ÷ 8 ≈ 6.37 MB.

We ran that exact clip through FileFlip's own FFmpeg engine at three of its bitrate presets, muxed a 96 kbps AAC track on top, and checked the output against the formula.

Every row lands within 2% of the formula, and every one comes in under it, tightening as the bitrate climbs. The gap is the encoder treating your number as a ceiling to approach rather than a target to hit exactly: a scene it can describe more cheaply than the budget allows, it does.

What's the difference between CBR and VBR?

Constant bitrate spends the same number of bits on every frame, whatever's happening in it. Variable bitrate spends more on frames that need it and less on frames that don't, so the average still lands where you set it, but no individual frame has to match that average.

FileFlip's audio Bitrate control produces a constant bitrate: every MP3 frame comes out within a byte of the last, whatever's playing that second. Its video Bitrate control produces a variable one: a frame packed with motion can cost many times what a still one does.

We measured both. Encoding our speech clip to MP3 at 192 kbps, all 287 frames landed at 626 or 627 bytes. Encoding the same 10-second clip to H.264 at 5 Mbps, the two keyframes averaged 543,336 bytes each and the 298 frames between them ranged from 1,496 to 87,774 bytes, a 59-fold spread.

A keyframe holds a complete picture; every frame after it only holds what changed since the last one, so a static shot compresses to almost nothing while a burst of motion costs nearly as much as another keyframe. That unevenness is what lets a video encoder put more of its budget where the picture is actually doing something.

What bitrate does a phone already record video at?

Apple doesn't publish an exact number, but a default recording is a reasonable one to check against. MacRumors measured an iPhone's default 1080p-at-30fps setting at about 65 MB per minute. Run back through the same arithmetic as above, that's roughly 8.7 Mbps combined video and audio, close to YouTube's own recommendation of 8 Mbps for a 1080p upload.

That puts a stock phone recording comfortably inside FileFlip's range. The top preset, 20 Mbps, is more than double what the phone itself used, so converting a phone clip is almost always about lowering the bitrate, not raising it toward some ceiling FileFlip can't reach.

What bitrate should you pick for a given resolution?

Match the destination's own recommendation rather than guessing. YouTube publishes recommended upload bitrates by resolution for standard frame rates:

FileFlip's presets top out at 20 Mbps, which covers everything up to 1440p with room to spare and falls short of what YouTube recommends for a genuine 4K upload. If you're delivering 4K, this control won't get you all the way there.

We measured what each bitrate actually buys at three resolutions, scoring every encode against the untouched 1080p source:

At 2.5 Mbps and above, the full 1080p frame wins outright: more pixels to work with is worth more than fewer bits per pixel once the budget covers it. At 1 Mbps it flips. 720p, at 68.4, beats both the full-resolution 1080p encode at 65.2 and the smaller 480p one at 62.1, because 1080p has too many pixels to describe on that budget and 480p is throwing pixels away it could still have afforded.

What bitrate should you pick for audio?

There's no VMAF or SSIM equivalent for audio, so the honest answer leans on reference points rather than a measured quality curve. Spotify's own streaming tiers are a useful anchor, even though the codec underneath is Ogg Vorbis, not MP3: Low around 24 kbps, Normal around 96 kbps, High around 160 kbps, and its top Premium tier around 320 kbps.

FileFlip's own MP3 presets sit on that same scale: 96, 128, 192, 256 and 320 kbps. We measured what each one actually produces:

The encoder consistently lands a kilobit or two above what you asked for, and even the top of the range comes out under a quarter the size of the uncompressed WAV. 96 kbps sits close to a streaming service's default tier, 192 falls between Spotify's High and Premium tiers, and 320 matches the top of its range. If you're not sure, 192 kbps is the middle of that scale and the one to reach for first; step up to 320 for music you'll listen to closely, or down to 96 for speech, where there's less in the signal to lose in the first place.

Common questions

Does a higher bitrate always mean better quality?

Only up to a point, and it depends what the encoder still has left to describe. Our own 1080p numbers above gained 26.6 points of VMAF going from 1 to 5 Mbps, then only 3.1 more points going from 5 to 10 Mbps, twice the size for a tenth of the improvement. Past a certain point you're paying for a difference you won't see.

Does changing Bitrate change the container?

No. Bitrate forces a full re-encode rather than a straight copy, but a re-encode can still land in the same container you started with. Whether a conversion is a fast copy or a slower re-encode is a separate question, covered in remuxing vs transcoding.

Should I set my upload bitrate above what my phone recorded?

Rarely. A phone shooting 1080p at 30 fps has already made its own quality decisions at roughly 8.7 Mbps; asking FileFlip for 10 or 20 Mbps on the way out won't add detail the original recording never captured. Match the bitrate to where the file is headed, not to how high the control goes.

Set the bitrate on a conversion

1. Open MOV to MP4 for video, WAV to MP3 for audio, or whichever pair matches your file, and drop it in.
2. Open Advanced options and set Bitrate. Video offers 1, 2.5, 5, 10 and 20 Mbps; audio offers 96, 128, 192, 256 and 320 kbps.
3. Convert and download. Nothing is uploaded: the file is encoded in your browser, there's no account, and it never reaches a server.

For the format details, see the MP4 format reference, the MP3 format reference and the WAV format reference.

How we measured this

• Video corpus: the same 10-second, 1920×1080, 30 fps H.264 segment of Big Buck Bunny (Blender Foundation, CC BY 3.0) used in making a video file smaller for email and remuxing vs transcoding, fetched with pnpm blog:corpora.
• Audio corpus: the 10.76-second spoken-word WAV (macOS say) used in lossy vs lossless compression, from the same command.
• Encoder: FFmpeg 8.1.2 with libx264, libmp3lame and libvmaf on macOS, passing only the flags FileFlip's own engine passes for a bitrate setting, -b:v <n> for video and -b:a <n> for audio, nothing else, matching apps/nextjs/src/utils/convert/ffmpeg.ts. This is also the path every MP3 export actually takes: no browser exposes an MP3 encoder to WebCodecs, so WAV-to-MP3 always runs through this engine rather than FileFlip's faster WebCodecs one.
• Arithmetic table: ffmpeg -i clip.mp4 -stream_loop -1 -i speech.wav -t 10 -map 0:v -map 1:a -c:v libx264 -b:v <n> -c:a aac -b:a 96000 out.mp4, output size checked against (bitrate + 96,000) × 10 ÷ 8.
• CBR/VBR table: ffprobe -show_entries packet=size,flags on the encodes above, grouped by the keyframe flag for video.
• Resolution and VMAF grid: the same -b:v encodes at FileFlip's own presets (1, 2.5, 5, 10 Mbps) across three resolutions, scored with FFmpeg's libvmaf filter after scaling both sides to 1920×1080 with bicubic, the method used in making a video file smaller for email.
• Audio ladder: node scripts/benchmark-audio-encoders.mjs <dir> mp3, extended for this post to print the min and max packet size at each bitrate. scripts/benchmark-video-encoders.mjs was likewise extended to print keyframe-versus-other frame sizes; its own bitrate ladder adds a -maxrate/-bufsize cap closer to a streaming target, so its exact figures differ from the uncapped, preset-matched ones quoted above, though the shape is the same.
• Caveat: one animated clip and one spoken-word clip are single data points. A live-action source or music will shift the absolute numbers while keeping the shape: keyframes will still cost far more than delta frames, and a lower resolution will still catch up as the bitrate gets tight, just not necessarily at exactly 1 Mbps. The MacRumors figure is third-party measurement, not a number Apple publishes.