Why compressing a video twice makes it look worse

Compressing a video twice looks worse than compressing it once to the same size because each pass through a lossy encoder throws away detail it cannot get back, and the second encoder treats the first one’s artifacts as real picture content worth spending bits on. The loss compounds: blockiness, smeared edges and banded gradients get reinforced rather than averaged out. The fix is to keep the original and do a single encode from it to whatever the final target is.

What a lossy encoder throws away

Video codecs such as H.264 and HEVC reach their file sizes by discarding information the viewer is unlikely to notice. Three mechanisms matter here.

Quantization. Each frame is broken into blocks, each block is converted into a set of frequency components (broad shapes and fine texture), and the fine components are rounded off. Lower bitrate means coarser rounding. Fine grain, fabric texture and the subtle gradient of a sky are the first to go. Once rounded, the exact values are gone from the file.

Motion prediction. Most frames are not stored in full. The encoder describes them as “this block moved from over there, plus a minor correction”. The corrections are themselves quantized, so a prediction error in one frame is carried forward, slightly smudged, through every frame that references it until the next full frame.

Chroma subsampling. Almost every consumer video stores color at a quarter of the resolution of brightness. The eye barely notices once. Fine red text on a blue background is where it shows.

None of this is reversible. Decoding a compressed file gives you an approximation of the original, and that approximation is what the next encoder sees.

Why the second pass compounds the damage

If compression simply removed detail, a second pass over an already-compressed file would have less to remove and might cost almost nothing. That is not what happens, for a few reasons.

Artifacts look like detail. The block edges, ringing around sharp lines and mosquito noise from the first encode are, to the second encoder, real high-frequency content. It spends bits trying to preserve them, which leaves fewer bits for the picture underneath, and then quantizes them again into new artifacts on top of the old.

The block grid rarely lines up. If the second encode uses a different resolution, a crop, or even a different codec, its blocks fall at different positions from the first encode’s blocks. The first grid’s edges are now inside the second grid’s blocks, where they are expensive to encode and get smeared.

Motion prediction degrades the reference. The second encoder predicts from frames that already contain prediction errors. Each generation adds its own, and errors accumulate through the chain of predicted frames.

Noise is added, not averaged. Two independent roundings do not cancel. Over many generations, a clip drifts toward the familiar look of a video that has been reposted a dozen times: soft, blotchy, with colors pooling into flat patches.

The practical consequence: a video compressed from the original straight to 10 MB will look noticeably better than one compressed to 50 MB, then to 20 MB, then to 10 MB, even though the final size is identical.

Where double compression happens without you noticing

Most people never deliberately compress a file twice. It happens through workflows.

• Messaging apps. Compress a clip on your Mac, send it through a chat app as media, and the app compresses it again on the way out. WhatsApp is the best-known example; the way around it is explained in WhatsApp video limits explained.
• Screen recording to editor to upload. The recorder encodes once. The editor exports (encode two). The video platform transcodes on upload (encode three). You control the first two; make the export high quality so the platform’s pass has good material.
• Downloading and reposting. A clip saved from a social platform has already been through that platform’s encoder. Posting it elsewhere runs it through another.
• Export, check, export again. Compressing a video, finding it too large, and compressing the result instead of the original. This is the most common self-inflicted case, and the easiest to avoid.
• Conversions that did not need to happen. Converting MP4 to MOV, or changing containers for compatibility, sometimes re-encodes when it could have copied the streams untouched.

How to avoid it

1. Keep the original. Treat the camera file as a master. Make compressed copies for sending and throw them away afterward; never overwrite the source. Tools that write a new file beside the original (rather than replacing it) make this automatic.
2. Encode once, to the final target. Decide the size or platform first, then go from the master directly to it. If you need three versions (email, chat, web), make three from the master, not a chain.
3. Trim without re-encoding when you can. In QuickTime Player, Edit > Trim followed by File > Save cuts the clip without touching the encoded frames. Only Export As re-encodes.
4. Send the file itself when the platform allows. Chat apps usually have a “send as document” option that skips their compression.
5. Export at higher quality than the platform’s final target. If a site will transcode your upload anyway, give it a clean, generous file; the only pass you control should be the gentlest.

Where a size limit is the reason for compressing at all, doing it in one step is the whole point of a tool like Manatee: its Shrink mode takes the original, you type the size in MB, and it finds the quality that fits in a single encode, writing a new file next to the untouched source. That is one generation, from the best material you have. The mechanics of choosing a bitrate for a size are in how to shrink a video to a specific file size on a Mac. Manatee cannot undo compression that has already happened, and no tool can: it can only avoid adding more.

When you have no original

Sometimes the compressed file is all there is: the clip a relative sent through a chat app, a download, an old export whose source is long gone. A few rules to limit further harm:

• Do not upscale. Encoding a 720p file at 1080p adds pixels the encoder has to spend bits on and invents no detail. Keep the output at the source’s resolution or lower.
• Match or exceed the source bitrate if size allows. Re-encoding at a higher bitrate than the source does not improve it, but it avoids adding a second layer of coarse quantization.
• Avoid unnecessary conversions. If a file plays and the only issue is the container, change the container with a stream copy rather than re-encoding. Converting between codecs is a full generation.
• If it must get smaller, do it once. Go straight from the file you have to the final size. Do not make a “medium” version first.

Expect the result to be visibly worse than the same size from an original. That is not a tool failing; it is the information already being gone.

Questions

Does converting MP4 to MOV (or back) lose quality?

Only if the video is re-encoded. MP4 and MOV are containers, and H.264 or HEVC video can be moved from one to the other with the streams copied intact. A converter that re-encodes by default will cost you a generation; one that copies streams will not. If a conversion is fast (seconds, not minutes), it was probably a copy.

Is it better to compress once heavily or twice gently?

Once, to the final target, from the original. Two gentle passes that end at the same size will look worse than one direct pass, for the reasons above.

How much quality is lost per generation?

There is no fixed figure; it depends on bitrate, resolution and content. At generous bitrates a second generation is hard to see. At the bitrates chat apps and email limits force, each generation is obvious. The guide to reducing MP4 file size on a Mac without losing quality covers what “without losing quality” realistically means.