How to Reduce Video File Size Without Visible Quality Loss

File size in video is not a mysterious property of the file — it is almost entirely determined by one equation:

File size (MB) ≈ total bitrate (Mbps) × duration (seconds) ÷ 8

A ten-minute clip at 8 Mbps is 600 MB. The same clip at 4 Mbps is 300 MB. Everything else — codec choice, resolution, frame rate — matters only because it changes how much quality you get per megabit. Once you see it that way, shrinking a video becomes a series of deliberate trades rather than guesswork.

What to Change, in Order of Effect

1. Duration — the change nobody considers

Size scales linearly with length, and most raw footage contains material nobody wants to watch: dead air at the start, a fumbled opening, long silent gaps. Cutting a 12-minute recording to 8 minutes removes a third of the file before any quality trade is made. If the goal is simply "make it fit", trimming is the only lossless lever available.

2. Bitrate — the direct control

Bitrate is the number of bits spent per second of video. Lower it and the file shrinks proportionally; lower it too far and you get blocking in dark scenes, smearing on fast motion, and banding in gradients like skies. Sensible targets for H.264:

Resolution / frame rate	Comfortable bitrate	Tight but usable	10 minutes at the tight rate
480p 30	1.5 Mbps	0.8 Mbps	60 MB
720p 30	4 Mbps	2 Mbps	150 MB
1080p 30	8 Mbps	4 Mbps	300 MB
1080p 60	12 Mbps	6 Mbps	450 MB
1440p 30	16 Mbps	9 Mbps	675 MB
2160p (4K) 30	40 Mbps	20 Mbps	1.5 GB

The "comfortable" column roughly matches what YouTube asks uploaders for. The "tight" column is where a talking-head or screen recording still looks fine but fast-moving footage starts to suffer. Content type matters enormously here: a static interview shot survives half these numbers, while handheld footage of moving water or falling snow will show artifacts even at the comfortable rate.

3. Resolution — downscale before you crush

Here is the counter-intuitive part: a clean 1080p file at 4 Mbps almost always looks better than a 4K file squeezed into the same 4 Mbps. The 4K version spends its limited bits describing four times as many pixels, so every one of them is described badly. If the target size forces a very low bitrate, downscale the resolution to match rather than starving the original.

Also worth checking: whether the delivery target can even use the resolution. A video destined for a phone-sized player or an email attachment gains nothing from 4K.

4. Frame rate — only when the content allows

Halving 60 fps to 30 fps saves roughly 20–30 % rather than the 50 % people expect, because consecutive frames are highly similar and inter-frame compression already exploits that. Screen recordings, slideshows and interviews are fine at 30 fps. Sports, gaming footage and anything with fast panning genuinely need 60. Never convert 30 fps up to 60 — it adds size and no information. Changing frame rate is worth doing only when the source is genuinely higher than the content requires.

5. Codec — the free 40 %

Codec choice changes how efficiently bits are used, at the cost of compatibility and encoding time:

Codec	Relative size at equal quality	Compatibility
H.264 / AVC	100 % (baseline)	Universal — every browser, phone, TV and editor
H.265 / HEVC	50–60 %	Good on modern devices; patchy in browsers
VP9	50–65 %	All major browsers; weaker hardware support
AV1	40–50 %	Modern browsers and recent hardware; slow to encode

The practical rule: if the video has to play absolutely anywhere — attached to an email, opened by a client on an unknown device — stay with H.264. If you control the playback environment, H.265 or AV1 halves the file at the same visual quality.

6. Audio — small but easy

Audio is usually a rounding error next to video, but uncompressed or over-specified audio is worth fixing. AAC at 128 kbps stereo is transparent for music in a video; 96 kbps is fine for speech; 64 kbps mono is acceptable for a screen recording narration. Across ten minutes, dropping 320 kbps to 128 kbps saves about 14 MB — not decisive on its own, but free.

CRF: Quality-Targeted Encoding

Instead of specifying a bitrate, most encoders accept a constant rate factor — you name the quality and the encoder spends whatever bitrate that requires, scene by scene. Simple scenes get small bits, complex ones get more, and the perceived quality stays even throughout.

• CRF 18 — visually indistinguishable from the source for most content. Large files.
• CRF 23 — the x264 default. Good quality, sensible size. The right starting point.
• CRF 26–28 — visible softening on detailed footage, still fine for screen recordings and talking heads.
• CRF 30+ — clearly degraded; use only when size is a hard constraint.

Each step of +6 roughly halves the file size. Note that CRF scales differ between codecs: CRF 23 in H.265 is noticeably higher quality than CRF 23 in H.264, so a straight number swap when changing codec is misleading.

The trade-off against fixed bitrate is predictability. CRF gives consistent quality and an unpredictable size; fixed bitrate gives a predictable size and inconsistent quality. When you have to hit a hard limit — an upload cap, an attachment ceiling — fixed bitrate, or two-pass encoding, is the correct tool.

Hitting a Specific Size Target

Rearrange the size equation to find the bitrate you are allowed:

Total bitrate (Mbps) = target size (MB) × 8 ÷ duration (seconds)

For a 25 MB email limit and a 3-minute clip: 25 × 8 ÷ 180 = 1.1 Mbps total. Subtract the audio (say 0.128 Mbps) and about 0.97 Mbps is left for video — which tells you immediately that 1080p is not realistic and 480p or 540p is the honest choice. Doing this arithmetic first saves several rounds of trial-and-error encoding. The video compressor takes a target size directly and works the bitrate out for you.

Common ceilings worth knowing: Gmail and most email providers stop at 25 MB, Discord allows 10 MB without a subscription, and messaging apps vary from 16 MB to several gigabytes. Above those, sharing a link beats compressing a file into unwatchability.

Two-Pass Encoding

In one-pass encoding the encoder makes bit-allocation decisions blind, having no idea what is coming next. In two-pass, it analyzes the whole file first, then distributes the bit budget with full knowledge of which scenes are complex. At the same target size, two-pass is visibly better on content with mixed complexity — the quiet scenes give up bits that the busy ones need. It costs roughly double the encoding time and is pointless when using CRF, which already adapts per scene.

Things That Do Not Help

• Changing the container. MP4, MKV and MOV are wrappers. Re-wrapping H.264 video from MOV into MP4 changes the size by a few kilobytes of metadata, not by anything meaningful.
• Zipping a video. Video is already entropy-coded; a ZIP archive typically saves under 1 %.
• Re-encoding an already-compressed file at the same settings. This is generation loss: it discards more detail while producing a file of similar size. Always re-encode from the highest-quality source you still have.
• Raising the bitrate above the source. Encoding a 2 Mbps file at 10 Mbps produces a 10 Mbps file containing 2 Mbps worth of detail.

A Working Recipe

1. Cut anything that does not need to be there. It is the only lossless saving.
2. Decide the delivery target — platform, device, hard size ceiling.
3. If there is a hard ceiling, compute the allowed bitrate and pick the resolution that suits it. Otherwise start at CRF 23.
4. Choose the codec by compatibility: H.264 to be safe, H.265 or AV1 when playback is under your control.
5. Set audio to 128 kbps AAC, or 96 kbps for speech.
6. Encode, then actually watch the result — check a dark scene and a fast-motion scene, which is where artifacts appear first.
7. If it is still too large, drop the resolution one step before dropping quality further.