Resolution, Frame Rate, and File Size

We tested what that multiplication actually costs. Holding quality constant, the same ten-second clip encoded at 480p came out 75% smaller than its 1080p version, tracking the 80% drop in pixel count almost exactly. YouTube's own upload guidance shows the same relationship at a bigger scale: 4K at 60 fps calls for around 454 MB a minute against 1080p at 30 fps's 60, a real gap of 7.6x for a theoretical jump of 8x in pixels per second.

Which control actually changes the file size?

Not the one most people reach for first.

• Bitrate sets the size. File size tracks bitrate times duration almost exactly, whatever Resolution or Frame rate you pick. Making a video file smaller for email has the measurements.
• Resolution and Frame rate decide what those bits describe. Fewer pixels or fewer frames per second means the same bitrate has less to cover, which raises quality, not the reverse.
• To shrink a file, lower Bitrate first. Open MOV to MP4 or MKV to MP4, pick Advanced options, and Bitrate is the control that moves the number on the download button.

Pixels per second, the only number that matters

A video is a stack of pixel grids shown one after another, and the encoder has to describe every pixel in every grid. Width times height times frame rate is the count of pixels it has to describe each second, and everything about how big or small a video gets starts there.

That table is arithmetic, not a measurement, so we checked whether file size actually follows it. We took our ten-second test clip and encoded it at 1080p, 720p and 480p with the quality setting fixed rather than the bitrate, the mode a camera or a quality-based encoder uses.

The size tracks the pixel count closely once quality, not bitrate, is what's held fixed. It undershoots the pixel ratio slightly at 480p because a fixed 96 kbps audio track takes up a bigger share of a smaller file, which is worth knowing before you read any single row as exact.

How much bigger is 4K60 than 1080p30, really?

Close to the 8x the arithmetic predicts, and sourced rather than guessed.

YouTube publishes recommended upload bitrates by resolution and frame rate, which makes a clean real-world comparison because the numbers reflect what a quality-based encoder actually spends, not a bitrate cap someone picked by hand.

The gap undershoots the theoretical 8x a little in both directions we tested, ours and YouTube's. Real footage has redundancy the arithmetic doesn't know about: a still background or a smooth gradient compresses to a fraction of its raw pixel count, and having more of those pixels doesn't cost the encoder much. The pixels-per-second number is the ceiling. What an encoder actually spends sits under it.

When does dropping resolution not hurt?

When the bitrate was already too low to use the pixels you had.

Our email-size measurements found the crossover directly: at 500 kbps, a 480p encode scored 48.3 VMAF against 1080p's 32.5, because the full-resolution version was starved of bits and turned blurry anyway. At 2 Mbps the ranking flips, and 1080p wins, because there's enough budget to use the extra detail. Below whatever bitrate your target sits at, the pixels you'd be dropping were never rendering cleanly in the first place.

The other case is the screen itself. A phone playing a 4K file back at 1080p is throwing away three quarters of every frame before you see it, so encoding at 1080p to start with costs you nothing you could have watched.

When does dropping frame rate hurt, even though it's cheap?

When the motion between frames couldn't have been guessed.

We tested this with a control. Starting from our 720p clip at 30 fps, we built two versions at 60 fps: one that just duplicates each frame, and one that uses motion-compensated interpolation to invent a real in-between frame. If frame rate cost scaled with frame count alone, the interpolated version should land close to the duplicated one. It does: 4.10 MB for duplicated frames against 4.09 MB for interpolated ones, both about 15% over the 30 fps baseline rather than the 100% the pixels-per-second table would suggest.

That's the honest limit of the test: our source is smooth, animated motion, which is exactly the kind an interpolator can invent convincingly and an encoder can predict cheaply. Real 60 fps footage of something erratic, like handheld motion, a crowd, or fast panning, carries information no interpolator could have reconstructed and no motion predictor could have guessed, which is why it costs closer to what YouTube's table shows and why watching it feels different even when the file size difference feels small on paper. Frame rate is the one of these two controls where dropping it removes something a later conversion cannot put back.

Setting resolution and frame rate on a conversion page

Bitrate is still the control to reach for if the goal is a smaller file. Resolution and Frame rate under Advanced options decide what that bitrate gets spent describing, and changing either one forces FileFlip into a real re-encode rather than the instant, lossless container swap you get when nothing about the video itself changes; see transcoding vs remuxing for what that costs in time.

Pick Resolution based on where the file will play. Match Frame rate to the source unless you have a specific reason to change it, since converting 60 fps footage down to 30 discards half the motion permanently, and there's no later conversion that gets it back.

Common questions

Will lowering Resolution in FileFlip shrink my file?

Only if you also lower Bitrate. Leave Bitrate alone and FileFlip spends the same number of bits on a smaller frame, which raises quality rather than cutting size, exactly what our CRF measurement above shows happening in reverse.

Do I need 60 fps for a screen recording or a tutorial video?

Usually not. Frame rate cost comes from motion an encoder can't predict, and most of a tutorial is a mostly static screen with small, easy cursor movements. 30 fps holds up fine, and converting up to 60 later can't add detail that was never recorded.

Is 4K worth converting down to 1080p to save space?

Only if you're not going to watch it at 4K. A file 8x the pixels per second of 1080p also holds real extra detail on a large or close screen; on a phone or a laptop it is detail you were never going to see, and MOV to MP4 with Resolution set to 1080p gets you a smaller file for exactly that viewing case.

Convert between them

FileFlip converts MOV and MKV to MP4 entirely in your browser, with Resolution, Bitrate and Frame rate under Advanced options. Nothing uploads, there is no account, and the file never leaves your machine.

How we measured this

• Source clip: the same 10-second, 1920x1080, 30 fps H.264 segment of Big Buck Bunny (Blender Foundation, CC BY 3.0) used in making a video file smaller for email, from test-videos.co.uk's sample library. One clip is one data point; a live-action source with less redundant motion would compress less generously at every resolution and frame rate tested here.
• Resolution test: FFmpeg 8.1.2, libx264 -crf 23, scaling to each target height with -vf scale=-2:H and a fixed 96 kbps AAC audio track, so quality rather than bitrate was held constant across the three encodes.
• Frame rate test: the 720p CRF 23 encode above as the 30 fps baseline. The duplicated 60 fps version used -vf fps=60, which repeats the nearest source frame; the interpolated version used -vf minterpolate=fps=60, FFmpeg's motion-compensated frame interpolation. Both were then encoded at the same CRF 23.
• YouTube figures: the recommended upload bitrate table for SDR uploads, read directly, as of August 2026. MB per minute is our own conversion from Mbps at the midpoint of each published range.
• Reproducing it: node scripts/benchmark-video-encoders.mjs <clip> in the repository reproduces the container and bitrate-mode measurements this post links to; the CRF and frame-rate figures above were run as one-off FFmpeg invocations using the commands described here, against the same corpus pnpm blog:corpora downloads.