Why is my video file so big?

A video file has no inherent size. The same 30 seconds of the same scene can be 4MB or 400MB, and nothing about the content decides which — four numbers do.

The useful thing about understanding them is that they are not equally worth changing. One of them costs you almost nothing and is where every sensible compressor starts. Two of them are visible immediately. One is usually a mistake to touch.

The only equation you need

file size ≈ (video bitrate + audio bitrate) × duration ÷ 8

Bitrates are in bits per second, duration in seconds, and the division by 8 converts bits to bytes. That is genuinely it. A 10-minute clip at 5 Mbps video and 128 kbps audio:

(5,000,000 + 128,000) × 600 ÷ 8 = 384,600,000 bytes ≈ 385MB

Everything else — resolution, frame rate, codec, how much motion is in the shot — matters only insofar as it changes what bitrate the file needed in order to look acceptable. Size itself is just bitrate multiplied by time.

1. Bitrate — the one to change

Bitrate is how many bits per second the encoder spent describing the picture. It is the direct cause of file size and the first thing to reduce, because the relationship between bitrate and visible quality is steeply diminishing: the last 40% of the bits in a typical phone recording buy almost nothing you can see.

Phone cameras are generous here by design. They encode in real time, on a battery, with no second pass to tidy up, so they overspend deliberately — it is cheaper to allocate extra bits than to risk visible artefacts in a shot that cannot be re-taken. An iPhone recording 4K at 60fps writes roughly 400 Mbps worth of H.265. That is about 24MB for every second.

Re-encoding that same footage with a target bitrate chosen for the size you need is where nearly all of the saving comes from, and for most clips it is the only change required.

2. Resolution — the honest second lever

Resolution is how many pixels each frame contains. 4K is four times the pixels of 1080p, which is roughly four times the detail to describe and therefore roughly four times the bits to describe it well.

Resolution matters because there is a floor underneath every resolution: a bitrate below which that many pixels cannot be described and the encoder starts smearing blocks instead. Push 1080p down to 400 kbps and you do not get a soft 1080p picture — you get a broken one. Encode the same footage at 480p and 400 kbps and it looks like what it is, a small video, which is a far better outcome.

These are the floors this tool uses, in video bitrate:

Resolution	Minimum that still looks like video
2160p (4K)	8 Mbps
1440p	4 Mbps
1080p	2 Mbps
720p	1 Mbps
480p	500 kbps
360p	300 kbps
240p	150 kbps

So resolution is not something to reduce for its own sake. It is what you reduce when the bitrate your target allows has fallen below the floor for your current resolution. Dropping a rung is how you keep a watchable picture at a bitrate that could not have held the larger one.

3. Duration — the lever nobody mentions

Size scales linearly with length, and no amount of encoder cleverness changes that. A clip twice as long needs half the bitrate to hit the same target.

This is worth saying plainly because it is the honest answer in the cases where compression genuinely cannot help. Fitting three minutes into 8MB means about 355 kbps for everything including audio — doable at 360p. Fitting thirty minutes into 8MB means about 35 kbps, which is below the floor of the lowest rung on the ladder. There is no setting that rescues that. Trimming is the answer, and a tool that pretends otherwise is wasting your time before handing you mud.

4. Frame rate — usually leave it alone

Frame rate is frames per second. Halving it from 60 to 30 does not halve the file: consecutive frames are highly similar, so most of them are stored as differences from their neighbours rather than as whole pictures, and dropping every other frame makes the remaining differences larger.

The saving is real but modest — typically 20–30%, not 50% — and the cost is immediately visible on anything that pans or moves quickly. For screen recordings of mostly-static content it is worth considering. For almost everything else, spend the same saving on bitrate instead.

What actually determines whether you are stuck

Put the four together and the question "can this fit?" has a precise answer:

1. Take your target size in bytes and multiply by 8 to get bits.
2. Subtract what the audio needs — 128 kbps stereo is normal, and 64 kbps mono is acceptable when the budget is tight.
3. Divide what is left by the duration in seconds. That is your available video bitrate.
4. Find the highest row in the table above whose floor is at or below that number. That is the best resolution your target can actually hold.

If step 4 finds no row, the clip is too long for the target at any watchable quality, and the fix is trimming rather than compressing.

The compressor on this site runs exactly that calculation before it starts, tells you the resolution and bitrate you will get, and — the part most tools skip — measures the finished file and re-encodes it if the encoder overshot. Nothing is uploaded; it runs on your own machine using your browser's hardware encoder.

FAQ

Why is my iPhone video so large compared to one I downloaded?

Because a downloaded video has already been re-encoded by whoever published it, usually twice, with time to spend on the second pass. Your phone encoded its copy in real time on a battery and deliberately overspent to avoid artefacts it could never fix. The same footage typically re-encodes to between a quarter and a tenth of its original size with no visible difference.

Does changing the container from MOV to MP4 make it smaller?

Almost never. The container is a wrapper describing where the audio and video streams sit in the file; the streams themselves are what take up the space. Remuxing a MOV to MP4 without re-encoding saves perhaps 1–2% of overhead. Any real saving comes from re-encoding the video stream itself.

Is H.265 or AV1 smaller than H.264?

Yes, meaningfully — H.265 reaches similar quality at roughly 30–50% less bitrate. The catch is playback: a file that will not open on the other person's device has not solved your problem. For anything you are sending to someone else, H.264 remains the format that opens on everything, which is why this tool targets it.

Why is my screen recording bigger than a camera video of the same length?

Sharp edges and text are expensive to encode, and screen content is almost entirely sharp edges. A camera image has natural noise and soft gradients that compress well; crisp text at high contrast does not. Screen recordings also often run at a high frame rate for content that barely moves, which wastes bits on near-identical frames.