Why your video file is 800 MB, and the one number that fixes it

A three-minute clip from a modern phone can easily be 800 MB. The same three minutes from YouTube is maybe 40 MB and looks, on a phone screen, roughly the same. Nothing magical happened in between. Almost all of the difference is one number.

File size is bitrate multiplied by time

That is not a rule of thumb, it is the definition. Bitrate is how many bits of data the file spends on each second of video. Multiply it by the number of seconds and you have the file size, near enough:

megabytes ≈ (bitrate in Mbps × seconds) ÷ 8

A 50 Mbps phone recording running for 180 seconds is (50 × 180) ÷ 8 = 1,125 MB. A 3 Mbps web export of the same footage is 67 MB. Same length, same resolution, same footage — one number changed, and it changed everything.

This is why "make the video smaller" almost always means "lower the bitrate", and why every other setting is either a way of influencing bitrate or a distraction.

So why is the phone recording set so high?

Because a camera is encoding in real time, on a battery, with no idea what is coming next. A proper encoder can look ahead across a whole scene, notice that the background has not moved for four seconds, and spend almost nothing on it. A phone recording to storage as it films cannot do that anywhere near as thoroughly, so it compensates by throwing bitrate at the problem — enough that even the hardest frame it might encounter still looks fine.

The consequence is that re-encoding phone footage is unusually rewarding. You are not squeezing an already-optimised file; you are giving a patient encoder a second pass at something that was encoded in a hurry. A 60–80% reduction with no visible difference is normal, which is not true when you re-encode something that came off a streaming service.

Resolution matters less than people expect

The instinct when a file is too big is to drop 4K to 1080p. That is a quarter of the pixels, so it should be a quarter of the size — and it is not. Encoders spend bits on detail and motion, not on pixel count directly, and a lot of what fills a 4K frame is fine detail that compresses efficiently anyway.

In practice, halving the resolution of a fixed-bitrate export does not halve the file at all: the bitrate is what you set, so the file is what you set. What dropping the resolution really buys you is the ability to lower the bitrate without it showing. 1080p at 4 Mbps looks clean. 4K at 4 Mbps looks like a mess of blocking whenever anything moves.

So the order of operations is: decide the resolution you actually need, then lower the bitrate as far as that resolution tolerates. Changing resolution alone, keeping bitrate fixed, mostly just makes a smaller picture at the same size.

Frame rate is the setting people forget

60 fps costs roughly 30–50% more than 30 fps at the same perceived quality — not double, because consecutive frames at 60 fps are more similar to each other and so compress better, but a lot.

Sixty frames a second is worth paying for in fast motion: sport, gaming, anything panning quickly. It is worth almost nothing for a talking head, a screen recording of someone scrolling slowly, or a locked-off shot of a product. If your phone defaulted to 60 fps and your subject is a person sitting still, half the frames are costing you money and buying nothing.

What the encoder is actually doing

Worth knowing, because it explains which footage compresses well and which does not.

A video is not a sequence of images. It is an occasional full image — a keyframe — followed by a run of frames that only describe what changed. If the camera is on a tripod and one person is talking, the difference between one frame and the next is a mouth and some noise, and those frames cost almost nothing to store. If the camera is handheld and swinging around a market, every pixel moves every frame and the encoder has to describe all of it.

Three practical consequences:

• Static footage compresses enormously well. A screen recording of a slide deck can drop by 95% and look untouched.
• Grain, rain, confetti and water are the enemy. They are high-frequency noise that changes randomly, which is exactly what motion prediction cannot predict. A grainy night shot can be several times the size of a clean daylight one at identical settings.
• Cuts are expensive. Every hard cut forces a fresh keyframe. A fast-cut montage costs more than one long take of the same length.

A practical starting point

These are the bitrates that look clean for typical content with a modern encoder. Grainy or fast-moving footage wants the upper end; a static screen recording will be fine well below the lower one.

• 4K (2160p) — 12–25 Mbps
• 1440p — 8–14 Mbps
• 1080p — 4–8 Mbps
• 720p — 2–4 Mbps
• Screen recording, any resolution — start at a third of the figure above; text stays sharp far below what video needs

Our video compressor works in these terms: it runs a real FFmpeg build inside the page, so you set a target and see the actual result rather than picking "medium" and hoping. Nothing is uploaded — the file is decoded and re-encoded in the tab.

Three things that do not work

Renaming or zipping it. Video is already compressed. A ZIP of an MP4 saves a fraction of one per cent, because there is no redundancy left for a general-purpose compressor to find.

Re-encoding at a higher bitrate. Quality lost in the first encode does not come back. Encoding a 2 Mbps file at 10 Mbps produces a 10 Mbps file containing 2 Mbps of picture, five times the size and not one bit better.

Repeatedly compressing the same file. Each pass compounds the artefacts of the last, the way a photocopy of a photocopy degrades. Always go back to the original and compress once, harder, rather than compressing a compressed file again.

If you only remember one thing

Work out what the video is for before you touch a setting. Something destined for a phone screen in a messaging app has no use for 4K at 50 Mbps, and 1080p at 4 Mbps will be indistinguishable to the person watching while being twenty times smaller. Nearly every enormous video file is a file encoded for a purpose it will never serve.