Bitrate, resolution and frame rate
Which of these settings makes the file smaller, and which one just makes it look worse?
One equation explains most of it
File size is, to a close approximation, bitrate multiplied by duration. Bitrate is how many bits per second the encoder is allowed to spend; duration is how many seconds it spends them for. Everything else — resolution, frame rate, motion, codec — changes how good the picture looks at a given bitrate, not how large the file is.
A worked example makes this concrete. A clip encoded at 5 megabits per second for sixty seconds contains 300 megabits of video data, which is 37.5 megabytes, plus the audio track and container overhead. That is arithmetic, not a measurement: the same sixty seconds at 2 Mbit/s is 15 MB, whatever is in the frame.
Resolution and frame rate are demand, not size
Raising resolution or frame rate does not directly enlarge the file. It raises how many bits the encoder needs in order to look acceptable. A 4K clip at 2 Mbit/s is the same size as a 720p clip at 2 Mbit/s; the 4K version simply looks far worse, because the same budget is being spread over nine times as many pixels.
This is why reducing resolution is such an effective way to shrink a video. You are not making the file smaller by changing the resolution — you are making a lower bitrate look acceptable, and then choosing that lower bitrate.
| Resolution | At 30 fps | At 60 fps |
|---|---|---|
| 3840 × 2160 | 249 million px/s | 498 million px/s |
| 1920 × 1080 | 62 million px/s | 124 million px/s |
| 1280 × 720 | 28 million px/s | 55 million px/s |
| 854 × 480 | 12 million px/s | 25 million px/s |
Those figures describe the number of pixels the encoder processes each second. Halving the frame rate halves that pixel count; dropping from 1080p to 720p reduces it to about 44% of the original. Frame rate has a second effect, though: it changes how motion feels. Halving the frame rate of a static talking head is nearly invisible; halving it on a fast pan is very visible indeed.
What a quality index actually does
Most modern encoders prefer a quality target over a bitrate target. You give a quality index, the encoder spends whatever bits that quality needs frame by frame, and the resulting bitrate varies with the content. This is usually the better setting to use, because it puts the bits where the picture needs them instead of wasting them on a still frame and starving a fast one.
The consequence is that a quality index does not tell you the file size in advance. Two clips encoded at the same index can differ by a large factor, and there is no way to know without encoding. If you must hit a size limit, either encode and check, or use a bitrate target and accept that quality will vary instead.
Motion is the hidden variable
Video codecs work by describing each frame as a difference from previous frames. When little changes — a locked-off camera, a slide deck, a face against a plain wall — the differences are tiny and the encoder needs very few bits. When everything changes — a handheld pan, confetti, rain, water, foliage in wind, a scene cut every second — almost nothing can be predicted and the bitrate climbs.
- Grain and sensor noise behave like motion: they change every pixel every frame and are expensive to encode.
- A shaky handheld clip costs far more than the same subject shot on a tripod.
- Screen recordings of mostly-static interfaces are extremely cheap until something scrolls.
- Fades and dissolves are more expensive than hard cuts, because every pixel changes slightly for a second or more.
Audio is small, until it is not
For most clips, audio is a rounding error: a stereo track at 128 kbit/s adds about a megabyte per minute. But on a heavily compressed, short, low-resolution clip it can become a noticeable share of the total. If you are pushing hard against a size cap, dropping to a lower audio bitrate, or to mono, is worth considering before you damage the picture any further. If the audio does not matter at all, removing the track entirely is a remux and costs nothing in quality.
A recipe that usually works
- Decide the largest screen the clip will actually be watched on, and cap the resolution to that.
- Keep the source frame rate unless the motion is gentle; halving it is a visible change, not a free saving.
- Encode with a quality index rather than a bitrate, then measure the result.
- If the result is too large, lower the resolution before lowering the quality further.
- Trim the clip. Duration is a direct multiplier on the whole equation, and thirty unnecessary seconds cost more than any setting.
Making a video smaller for email
Email limits apply to the finished attachment, so duration is the first thing to check. Trim anything unnecessary, then lower the resolution to 720p or 480p when the clip will be viewed in a message rather than on a large display. The lower pixel demand lets the encoder use a much smaller bitrate without destroying detail.
If the attachment still misses the provider limit, shorten it or share it through an approved file-transfer service. Re-encoding the same long clip again and again at lower quality eventually produces a bad-looking file that can still be too large, because duration keeps multiplying the bitrate.
What this cannot tell you
There are no target bitrates in this guide on purpose. A recommended number depends on the codec, the encoder implementation, the content and the viewing conditions, and any figure quoted without those four things is decoration. Encode a thirty-second sample of your own clip at two settings and look at both — that comparison is worth more than any table someone else measured on someone else's footage.
One more limit specific to browser-based encoding: your device decides the pace. Encoding is genuinely heavy work, phones throttle when they get warm, and a long clip at a high resolution may be more than a particular device can finish. That is a hardware boundary, not a setting you can adjust away.