Lower Resolution or Bitrate? What to Cut First

Below: what each lever really does to the file, why the right order flips with content, a scorecard for five common types of video, and a two minute test that settles it for your own clip.

Which four levers actually change file size?

Start from the one formula that governs all of it. A video file is its bitrate multiplied by its length:

megabytes ≈ (megabits per second × seconds) ÷ 8

One minute at 8 megabits per second is 8 × 60 ÷ 8 = 60 MB. One minute at 5 megabits per second is 37.5 MB. The full derivation, including what the audio track adds, is in video compression by the numbers. What matters here is that only two things appear in that formula: bitrate and duration. Resolution and frame rate are not in it at all.

Duration is the only free lever. Cut ten seconds of dead air from a sixty second clip and the file shrinks by a sixth at no quality cost. Trimming belongs at the top of every list, before any setting is touched.

Bitrate is the direct lever. Lower it and the file shrinks in exact proportion. The cost is that the encoder has fewer bits to describe each frame, and when it runs short it throws away detail and then starts showing blocks.

Resolution is an indirect lever. A 1280 by 720 frame has 921,600 pixels and a 1920 by 1080 frame has 2,073,600, so 720p carries 44% of the pixels of 1080p. Fewer pixels need fewer bits to look clean, which lets you lower the bitrate without the picture falling apart. But if you lower the resolution and hold the bitrate fixed, the file is exactly the same size. You just spent the same bits on a smaller picture.

Frame rate is also indirect, and weaker than it looks. Halving the frame rate does not halve the bits needed, because consecutive frames at 60 per second are more alike than consecutive frames at 30, and the encoder only pays for what changed.

YouTube's own recommended upload encoding settings show both indirect effects in one table. Its SDR recommendations as of this writing:

Resolution	Pixels per frame	Bitrate at 24 to 30 fps	Bitrate at 48 to 60 fps
1080p	2,073,600	8 Mbps	12 Mbps
720p	921,600	5 Mbps	7.5 Mbps
480p	409,920 (854 × 480)	2.5 Mbps	4 Mbps

Two things fall out of that. Dropping from 1080p to 720p removes 56% of the pixels but only 37.5% of the recommended bitrate (8 to 5). And doubling the frame rate adds 50% to the bitrate, not 100%. Per pixel, per frame, 1080p at 30 fps gets about 0.13 bits while 720p at 30 fps gets about 0.18, because each pixel in a smaller picture is carrying more of the scene's detail. Neither lever is a straight line, which is exactly why the order you pull them in matters.

Why does the right order depend on your content?

Because the three quality levers fail in three different ways, and different footage hides different failures.

• Too little bitrate fails as blocking, smearing on motion, banding in gradients and mosquito noise around edges. It is worst where the picture changes a lot between frames: handheld movement, water, foliage, confetti, fast pans.
• Too little resolution fails as softness. Fine detail blurs, and text is the first thing to become unreadable. On a phone held at arm's length, a 720p talking head is very hard to tell from 1080p. A 720p code editor with a 12 pixel font is not.
• Too low a frame rate fails as stutter. Motion that used to be smooth steps from position to position. A slide deck at 10 fps looks identical to one at 60, because nothing is moving. A skateboarder at 15 fps looks broken.

So the question is "which failure will my footage hide." A shaky phone clip already has motion blur and noise, so softness costs it little. A pin sharp, almost motionless screen recording cannot absorb softness at all.

Which lever should you cut first? The scorecard

This is the ordering for five common kinds of video. "First" is the cut that saves the most for the least visible damage. "Never" is the cut that ruins that content type fastest, no matter how tempting the savings look. In every row, trimming dead time comes before all of it.

Content	Cut first	Cut second	Never cut
Screen recording (UI, code, documents)	Frame rate, to 30 or lower (slides can go to 15 or below)	Bitrate or quality setting: near identical frames are cheap, so a higher CRF holds up	Resolution below the point where the smallest text stays readable, or any non whole number downscale
Talking head (webcam, interview, vlog)	Resolution, 1080p to 720p for phone viewing	Bitrate, moderately: a mostly static background compresses well	Frame rate below the source's 24, 25 or 30: mouth movement starts to step
Handheld action (sport, travel, kids, pets)	Resolution, before bitrate, so the remaining bits per pixel stay high	Duration: trim harder, because this content is expensive per second	Bitrate pushed far down, and frame rate: blocking and judder both show immediately on motion
Animation and motion graphics (flat colour, titles, explainers)	Bitrate or quality setting: flat fills are cheap to encode	Resolution, by an exact half (1080p to 540p, 4K to 1080p)	Frame rate: animation timing is authored, and dropped frames break it
Slideshow (photos, still slides with captions)	Duration: shorten the hold time on each slide	Frame rate, since nothing moves between cuts	Resolution while captions or photo detail are the point of the video

Two rows deserve a closer look, because they are where the usual advice goes wrong.

When does cutting resolution look better than cutting bitrate?

Whenever the footage is busy and the viewing screen is small.

Picture a clip that has to land under a size limit. At 1080p, the encoder spreads the bits across 2.07 million pixels per frame. On a handheld shot where every pixel shifts every frame, the bits run out and the encoder resorts to coarse blocks, especially in shadows and on moving edges. At 720p, the same bits cover 0.92 million pixels, each pixel gets more than twice the share, and the picture stays clean. It is softer, but softness on a six inch screen is close to invisible, while blocking is visible at any size. A clean smaller picture beats a broken larger one.

The rule of thumb: if a budget forces the bitrate below what the resolution needs, drop the resolution one step and give the saved bits back to the picture. If you are hitting a hard size target, compressing to an exact file size walks through when the target becomes impossible without cutting length or resolution.

The one case where this flips is text. A 720p recording of a 1080p screen does not look softer, it looks illegible, because a one pixel text stroke cannot survive a 1.5× downscale cleanly. For screen content, keep the pixels and take the savings elsewhere.

Why is frame rate the cheapest cut for screen content?

Not because it saves the most bytes. Because it costs the least to look at.

A screen recording at 60 frames per second writes sixty pictures a second of a window that is mostly not moving, and a frame that repeats the previous one costs almost nothing. So dropping to 30 saves little on static stretches. The saving concentrates in scrolls, window drags and cursor sweeps, where every frame is different and expensive, and where 30 fps looks exactly as usable as 60 to anyone following a tutorial. The visible cost is close to zero, which makes it the cheapest cut per byte even when the byte count is modest.

Two conditions apply. First, set it at recording time. FFmpeg's fps filter converts after the fact by "duplicating or dropping frames as necessary", which works but cannot give back what a 60 fps capture already committed to, and recording at the lower rate from the start is simpler. Second, it only pays under a quality target. Under constant bitrate the encoder fills the same pipe whether it is writing 30 frames or 60, so the file stays the same size and only the smoothness drops. If you cut the frame rate and the file size did not move, that is the diagnosis. The full walkthrough of recorder settings, keyframe intervals and clean downscaling for screen captures is in why screen recordings get so big.

How do you test the trade in two minutes?

Stop guessing and run both candidates on the part of your video that is hardest to encode.

1. Find the worst ten seconds. For camera footage, that is the fastest movement or the darkest scene. For a screen recording, it is the smallest text or the fastest scroll.
2. Cut that stretch out with the trimmer so each test encode takes seconds, not minutes.
3. Encode it twice. Version A keeps the full resolution and lowers the bitrate: run it through the compressor at Balanced, which is CRF 28. Version B keeps a generous quality setting and lowers the resolution: run it through the resizer at 720p, which scales by height and encodes at CRF 22. CRF is FFmpeg's "constant quality mode", documented in the libx264 encoder options, so each encode spends whatever each frame needs to hit its quality level.
4. Compare the sizes, then look at both on the screen your audience will use. If the video is going to phones, look on a phone. Pause on the frame you picked in step one.
5. Keep the smaller one that holds up, then run the full clip with the winning setting.

If both hold up, you have room to push further. If neither does, the answer is usually duration: the clip is simply too long for the budget, and no setting will fix that without visible damage. For what "holds up" means in practice, and which CRF sits where on the visible scale, see compressing without visible quality loss.

FAQ

Is 720p always smaller than 1080p?

No. File size is bitrate times duration, and resolution is not in that formula. A 720p file encoded at 8 Mbps is exactly the same size as a 1080p file at 8 Mbps. Under a quality target such as CRF, the same clip at the same setting will come out smaller at 720p, because fewer pixels need fewer bits to reach the same quality. But a 720p encode at a generous quality setting can easily be larger than a 1080p encode at an aggressive one. Compare the settings, not the labels.

Does lowering frame rate reduce file size?

Under a quality target, yes, but by less than the ratio suggests. YouTube's upload recommendations put 1080p at 8 Mbps for 24 to 30 fps and 12 Mbps for 48 to 60 fps, so halving the frame rate on typical content saves roughly a third of the bitrate, not half. On a mostly static screen recording the saving is smaller still, since repeated frames were already nearly free. Under constant bitrate it saves nothing at all: the encoder fills the same number of megabits per second regardless of how many frames it writes.

Which loses more quality, resolution or bitrate?

It depends on the content. On busy camera footage, cutting bitrate loses more: it blocks on motion while a resolution cut only softens. On screen recordings and anything with small text, cutting resolution loses more, because text goes unreadable first. When in doubt, encode both and look.

Can I shrink a video without changing anything visible?

Usually, yes, because video straight off a phone or a screen recorder tends to carry more bitrate than the picture needs, and a sensible quality setting can take the excess without a visible difference. The limit is a video that was already compressed hard: there is no spare bitrate left, and any further cut shows. Trimming is the one change that is guaranteed invisible, because it removes seconds rather than detail.

Run the same clip through two settings

The whole decision fits in one test. Take your hardest ten seconds, run it through the compressor and the resizer, and keep whichever version is smaller and still looks right on the screen it is headed for. The file is read into browser memory and encoded on your own CPU, so nothing is uploaded and nothing waits in a queue.

The free tier takes inputs up to 200 MB and adds a small watermark in the corner of video exports. Pro removes both and adds compression to an exact target size, instant lossless trim and mute, contact sheets and the settings advisor, for $4 a month billed as $24 every six months, or $79 once for life.