Which Video Resolution to Choose, and What Each Step Costs in Megabytes

A step down the ladder is a squaring, not a halving

The names on the ladder are heights, which is why the arithmetic surprises people. 1080p to 720p sounds like a two-thirds move, and on the height it is: 720 is 67 % of 1080. But the width came down in the same proportion, so the area — the number of pixels the encoder actually has to describe — fell to 67 % of 67 %, which is 44 %. In whole numbers, 1920 × 1080 is 2,073,600 pixels and 1280 × 720 is 921,600. You did not remove a third of the picture. You removed more than half of it.

The same squaring runs the other way and explains why 4K files are so alarming. 3840 × 2160 is 8,294,400 pixels, exactly four times 1080p, because both dimensions doubled. 1440p sits between them at 3,686,400, or 1.78 times 1080p. Once you see the ladder as areas rather than as heights, the sizes stop being mysterious: each rung is roughly half the area of the one above it, and the file sizes broadly follow, though not exactly, for reasons the next section covers.

Bitrate decides the size; resolution only decides what bitrate is reasonable

This is the correction that saves the most wasted time. A file's size comes from its bitrate multiplied by its duration, and a frame size is not a bitrate — it is only a hint about what bitrate would look sensible. You can encode 4K at 1 Mbit/s and get a small, hideous file, and you can encode 480p at 20 Mbit/s and get a large, pristine one. Nothing in the resolution forces either outcome.

So before you resize anything, work out what the file already spends per second. Divide its size in megabytes by its duration in seconds and multiply by 8,000; that gives kilobits per second. Compare that with the ladder. A phone recording at 1080p that comes out around 20 Mbit/s is spending generously and has a great deal to give back. A 1080p file that a chat app handed you at 1.5 Mbit/s is already below what YouTube would recommend for 480p, and resizing it will win you almost nothing — the picture was never carrying that much information in the first place.

That is also why a resize can produce a bigger file than it started with, which looks like a bug and is not one. The resizer here encodes at a fixed quality target, CRF 23, and a quality target asks the encoder to spend whatever the picture needs. If the input was compressed far harder than CRF 23 would have compressed it, then re-encoding it at any resolution costs more bits than it currently occupies. When that happens, resolution was never your problem and the video compressor with its adjustable quality is the tool you actually wanted.

Why halving the pixels does not halve the bytes

Divide YouTube's recommended bitrate at each rung by the pixels in a frame and by the frame rate, and you get bits per pixel per frame: about 0.16 at 2160p, 0.13 at 1080p, 0.18 at 720p, 0.20 at 480p. The number does not fall as the picture shrinks — it drifts upward at the bottom of the ladder. Smaller frames are less compressible per pixel, because a codec saves bits by finding large regions that repeat or move together, and there is less room for such regions in a small picture. Detail that a big frame spreads over sixteen pixels is crammed into four, where it looks like noise, and noise is the most expensive thing a video codec ever has to encode.

The practical version of that is simple. Going from 1080p to 720p removes 56 % of the pixels but only about 37 % of the recommended bitrate. Going from 1080p to 480p removes 80 % of the pixels and about 69 % of the bitrate. The reward is still large; it is just smaller than the pixel arithmetic promised. And the biggest single step by far is the first one out of 4K: 2160p to 1080p cuts the recommended bitrate to a fifth, which is why a 4K holiday clip is the one file where resizing changes everything.

What the tool does with the number you type

You give it a width and it derives everything else. The scaler is told to produce your width and to compute the height from the source's own aspect ratio, rounded to an even number because H.264 works in blocks that need it. The resampling uses Lanczos, which is a sharper filter than the default and the right choice when you are throwing pixels away. The picture is then re-encoded with libx264 at a fixed CRF of 23, the file is written as an MP4 with the faststart flag so the index sits at the front, and the audio is copied across untouched rather than re-encoded.

Two consequences follow from that description and both matter. First, because the quality target is fixed, resolution is the only lever this tool gives you — if you need to control the trade between quality and size as well, that is the video compressor's adjustable CRF, and running both means paying for two generations of encoding rather than one. Second, because the audio is copied byte for byte, its contribution to the file cannot shrink no matter what you do to the picture: a soundtrack at 128 kbit/s weighs 0.96 MB per minute before and after, so on a five-minute clip 4.8 MB of the result is fixed from the start.

The preset buttons cover 854, 1280 and 1920 pixels wide — 480p, 720p and 1080p on a widescreen source — and the number box accepts anything from 120 to 3840, so 1440p and 2160p are reachable by typing 2560 and 3840. Nothing in the tool stops you entering a width larger than the source has, and if you do, it will dutifully upscale: more pixels, a bigger file, and not one extra piece of detail, since the information simply is not in the original. Check what your file actually is before you choose a number.

Choosing the rung by where the video is going

Match the rung to the screen that will actually show it. A clip destined for a chat window, a message thread or a slide in a meeting is being shown in a rectangle a few hundred pixels wide, and 720p is already more than that surface can resolve; 480p is often indistinguishable. A video for a website that will play in a column of text is in the same position. Anything that will go full-screen on a laptop or a television deserves 1080p. 4K earns its weight only when the viewer has a 4K screen and a reason to look closely — a landscape, a product, footage you intend to crop into later.

One case argues against resizing at all. If the destination is a platform that re-encodes everything on upload, giving it the largest sensible version and letting its own encoders build the ladder produces a better result than pre-shrinking, because their second-generation encode then starts from more information rather than less. YouTube publishes the bitrates it wants for exactly this reason. Resize when you are the one delivering the final file — an email, a message, a form with a limit, a page you control. Do not resize when you are feeding a machine that is going to redo the work anyway.

Frequently asked questions

I resized to 720p and the file barely shrank. Why?

Almost certainly because the source was already encoded thinly. Work out what it spends per second — size in megabytes, times 8,000, divided by duration in seconds — and compare it with the 5 Mbit/s that 720p typically wants. If the original was already below that, there was nothing for the resize to recover, and the fixed quality target of CRF 23 may even have spent more. Resizing rewards generous sources: a camera original, a 4K recording, an export from editing software. It does almost nothing for a file that has already been through a messaging app.

Should I resize first or compress first?

Do as few passes as you can, because each one costs a generation of quality. Resizing already re-encodes at CRF 23, so following it with the compressor means two full encodes of the same footage. The efficient order is to resize once, look at the result, and only reach for the compressor if it is still over your limit. Going the other way — compressing then resizing — is worse, because you would be scaling down a picture that has already been degraded and then re-encoding the degradation.

Can I make a 720p video into 1080p?

The tool will let you, and you should not. Upscaling invents pixels by interpolating between the ones you have; it cannot add detail that was never recorded. What you get is the same picture, slightly softer from the interpolation, in a noticeably bigger file. The only honest reasons to upscale are technical: a platform or an editing timeline that insists on a minimum resolution, or matching one clip to others in a sequence. If you only want the video to look better, spend the effort on a lower CRF at its native resolution instead.

Does resizing damage the sound?

Not at all — the audio is copied across without being decoded, which costs no time and loses nothing. The flip side is that its share of the file is fixed. If the original carried a 320 kbit/s soundtrack, the resized version still carries a 320 kbit/s soundtrack, weighing 2.4 MB per minute regardless of what you did to the picture. On a short clip that is invisible; on a forty-minute recording it is 96 MB you cannot shrink here. If the sound is the bulk of the problem, the video compressor, which re-encodes audio to 128 kbit/s, is the tool that will actually move it.