How to compress a video without losing quality

The honest version of this answer starts with a distinction, because the phrase "without losing quality" means two different things and only one of them is achievable.

Mathematically lossless means every pixel is bit-identical to the original. For a video that has already been encoded as H.264 or H.265 — which includes everything your phone, camera or screen recorder produces — this is close to pointless. The file is already compressed by a lossy codec; a lossless wrapper around that data saves a percent or two. There is no spare redundancy left to find.

Visually lossless means you cannot tell the difference at normal viewing distance. This is very achievable, and for most footage it comes with a 60–80% size reduction. It is what people actually want when they ask the question.

Why there is so much room

Your phone encodes video in real time, on battery power, with no opportunity to reconsider. It therefore overspends on purpose: allocating extra bits is cheap, while visible artefacts in a shot that cannot be re-taken are not. An iPhone recording 4K60 writes roughly 400 Mbps of H.265, around 24MB per second.

Re-encode that with a bitrate chosen deliberately and most of it turns out to have been describing detail nobody can see. The relationship between bitrate and perceived quality is steeply diminishing — the last 40% of the bits in a typical recording buy almost nothing.

The settings that matter, in order

1. Keep the resolution if the bitrate can hold it

Every resolution has a floor: a bitrate below which that many pixels cannot be described, and the encoder starts producing blocks instead of detail.

Resolution	Floor (video bitrate)
2160p (4K)	8 Mbps
1440p	4 Mbps
1080p	2 Mbps
720p	1 Mbps
480p	500 kbps
360p	300 kbps
240p	150 kbps

Above the floor, keep the resolution. Below it, drop a rung. A clean 720p picture looks better than a broken 1080p one every time — and this is the single most common mistake in manual compression: holding on to 1080p at a bitrate that cannot sustain it, and getting mud with lots of pixels.

2. Do not touch the frame rate

Halving 60fps to 30fps saves perhaps 20–30%, not 50% — consecutive frames are stored as differences, and dropping every other frame makes each remaining difference larger. The cost shows up immediately on anything that pans. Spend the same saving on bitrate.

The exception is screen recordings of mostly-static content, where 60fps genuinely is wasted.

3. Give audio what it needs and no more

128 kbps stereo AAC is transparent for speech and fine for music. On a tight budget, 64 kbps mono is perfectly acceptable for talking — but notice what happens on a small target: 128 kbps of audio across ten minutes is 9.6MB. Against a 20MB limit that is half the budget spent on sound.

4. Keep H.264 unless you control the playback

H.265 and AV1 reach the same quality at 30–50% less bitrate, which is a real advantage. But a file that will not open on the recipient's device has not solved anything, and H.264 is the only codec that opens on everything. For anything you are sending to someone else, that compatibility is worth more than the bitrate saving — which is why this tool targets H.264.

5. Encode once, from the original

Every lossy re-encode compounds. Compressing an already-compressed copy means the second encoder is faithfully preserving the first one's artefacts and spending bits to do it. Always start from the largest original you have, and if you need three different sizes, make all three from that original rather than from each other.

Why "measured" matters more than any setting

Here is the part most tools get wrong, and it has nothing to do with quality settings.

A bitrate target is a goal, not a contract. Encoders overshoot, especially on high-motion content, and the container adds 1–2% of its own. So a tool that computes a bitrate for 20MB and stops has produced a file that is approximately 20MB — which, if it came in at 20.4MB, is a failed upload and a wasted two minutes.

The fix is to measure the output and re-encode at a corrected bitrate if it came in over. That is the difference between a file that fits and a file that nearly fits, and it is the step almost every competitor skips. It is also why you should be suspicious of any compressor that promises a size without telling you it verified one.

The practical recipe

1. Start from the original, not from a copy.
2. Pick the target size you actually need — the real platform limit, not the published one. The platform limit pages have the dated numbers.
3. Keep the source resolution if the available bitrate clears its floor; otherwise drop one rung.
4. Leave the frame rate alone.
5. 128 kbps stereo audio, or 64 kbps mono if the budget is tight.
6. H.264, unless you control what plays it.
7. Verify the output size before you rely on it.

Compress to 20MB or to 50MB does all seven: it works out the best resolution your target can hold, encodes with your machine's own hardware encoder, measures the result, and re-encodes on a corrected bitrate if the first pass came in over. Nothing is uploaded and there is no watermark.

FAQ

Can you compress a video with no quality loss at all?

Only by remuxing — rewrapping the existing streams into a different container without re-encoding them — and that saves 1–2% at most. Any meaningful size reduction of an already-compressed video requires re-encoding, which is lossy by definition. What is achievable is visually lossless: a 60–80% reduction with no difference you can see at normal viewing distance.

What bitrate should I use for 1080p?

Between 2 and 8 Mbps depending on motion: around 2 Mbps is the floor where 1080p still holds together, 4–5 Mbps is comfortable for most footage, and 8 Mbps is generous enough for fast action. See what bitrate you need for 1080p for the full breakdown, including why your source bitrate matters.

Is it better to lower the resolution or the bitrate?

Lower the bitrate first, until you reach the floor for your resolution — then lower the resolution. Those floors are in the table above. Staying at a resolution the bitrate cannot sustain is what produces the blocky, smeared look people associate with compression, and it is avoidable.

Does compressing twice make it worse?

Yes, and noticeably. Each lossy encode treats the previous one's artefacts as real detail worth preserving, so errors compound and bits get spent on them. Always re-encode from the largest original you have rather than from an already-compressed copy.