DEV Community

Max/Wang
Max/Wang

Posted on

How Many Times Can You Compress a Video Before It Looks Bad?

If a compressed video looks worse than you expected, the problem usually isn't the compressor — it's that the file was already compressed once before you touched it.

The result looks worse than it should — here's why

You compress a video, and it comes out blockier or softer than you expected, even on a setting that's supposed to keep quality close to the original. Nine times out of ten, the file you fed into the compressor wasn't actually the original — it was already a compressed copy, and you just compressed it a second time without realizing it.

This happens constantly without anyone noticing, because the first compression pass usually isn't a choice you make on purpose. You record a video, a messaging app or social platform re-compresses it the moment you upload or send it, you download that version back down later, and then run it through a compressor again to hit a size limit somewhere else. By the time you're looking at the final result, it's had two or three rounds of lossy compression stacked on top of each other — and each one throws away more detail than the last, in a way that adds up faster than most people expect.

Why compression loss compounds instead of staying flat

Every time a video is compressed, the encoder makes judgment calls about which detail to keep and which to discard, based on what it can actually see in that specific file at that moment. The first pass discards genuine picture detail — fine texture, subtle gradients, motion blur, small variations in color — because that's the least noticeable place to save space when the source is clean. Second and later passes don't have that untouched detail to work with anymore. The encoder is now looking at a file that already has some blockiness and softness baked into it, and it has to make the same kind of decisions again, except this time there's less real information left to preserve.

Here's the part that makes it worse than simply "losing a bit more each time": some of what the second pass now treats as real picture detail is actually just artifacts left over from the first compression. Blocky edges around a face, slight color banding in a sky, a faint checkerboard pattern in a dark scene — the encoder doesn't know these came from a previous compression pass rather than the original footage, so it spends bits trying to preserve them as if they mattered, which leaves even less budget for the parts of the image that actually do.

It's the same idea as photocopying a photocopy. The first copy loses a little sharpness around the edges of the text. Copy that copy, and you're not starting from the clean original — you're compounding the loss that's already there, and the machine has no way of knowing which smudges were in the first copy versus the real page. Video compression works the same way, just with motion and color instead of ink on paper.

Where the extra compression passes sneak in

  1. Recording — Phones and screen recorders already compress footage as they save it. This is the real original, and it's already been through one encoding pass before you've done anything at all.
  2. Uploading somewhere first — Instagram, WhatsApp sent "as video," Discord, and most messaging apps re-encode whatever you send through them, usually at a lower bitrate than you'd choose yourself, to keep their own storage and bandwidth costs down.
  3. Downloading that version back — If you then save the file from the app or platform instead of pulling it from your own camera roll, you're now working from the re-compressed copy, not the source — and there's often no visual clue that this happened.
  4. Editing and re-exporting — Trimming or adding captions in a phone editing app usually means a full re-encode of the whole clip, even for a one-second cut — another pass, whether or not you changed the picture itself.
  5. Compressing again to hit a new limit — Squeezing that already-compressed, already-re-exported file down further for a different platform's size limit is the pass where the accumulated loss finally becomes visible to the naked eye.

None of these individual steps is unreasonable on its own — trimming a clip, sending it to a friend, then needing it smaller for a different app is a completely normal sequence of events. The problem is that each step quietly re-encodes the file, and nothing in the process warns you that it's happening. By the time you notice the quality drop, you're usually several steps removed from the original file and it's not obvious which step actually caused it.

How to tell if a file has already been compressed

A few practical signs are worth checking before you compress something a second time:

  • If the video came from anywhere other than your own camera roll or recording software — downloaded from a chat, saved from a social app, pulled off someone else's share link — assume it's already a compressed copy rather than a source file.
  • Zooming into a still frame and looking for faint blocky squares in flat areas like skies or walls, or a slightly smeared look around fast-moving edges, is a reasonably reliable tell that a file has already been through at least one lossy pass, even if it still looks fine at normal viewing size.
  • File size relative to length and resolution is another clue: a five-minute 1080p clip sitting at only 15MB has almost certainly already been compressed hard by whatever app touched it last, since an untouched original at that resolution and length is normally many times larger.

How to avoid it

The fix is simpler than it sounds: always compress from the earliest, least-processed copy of the file you can find — usually the one still sitting in your camera roll or original recording folder, not a version you re-downloaded from somewhere else. If you know a video is headed to more than one place with different size limits, compress once at the lowest target size you'll actually need and reuse that single file, rather than compressing a fresh copy for each platform starting from an already-compressed one each time.

It also helps to match the compression level to what the video is actually for. If there's any chance you'll re-edit or re-export a clip later — adding captions, trimming it further, repurposing it for a different platform — keep it at a lighter setting the first time. SquishyFile's "Light" level trims redundant data without pushing the bitrate down aggressively, leaving more headroom before a second pass becomes visible, compared to jumping straight to the smallest possible file. Save "Max squish" for the last step before sending, once you know there's no next re-encode coming after it.

If storage allows, it's worth keeping the original, uncompressed recording around for a while even after you've shared a compressed version — a video you can always compress again from scratch is a lot more forgiving than one where the only copy left has already been through two or three rounds of lossy encoding.

FAQ

Is there a hard number of times I can compress a video?
Not a fixed one — it depends on how aggressive each pass is and how much motion or fine detail the footage has to begin with. A few light passes on simple footage can look fine; two or three aggressive passes on anything with texture or motion usually won't.

Does re-compressing the same file with the same settings make it worse each time?
Yes, even with identical settings, because the encoder is working from a file that already lost some detail last time — there's less real information to preserve on each subsequent pass, even though the settings you're choosing haven't changed.

If a platform re-compresses my upload anyway, is compressing it myself first pointless?
No — starting from a smaller, well-compressed file usually means the platform's own re-encode has less work to do and causes noticeably less additional damage than feeding it a huge, high-bitrate original the platform then has to crush down on its own.

Does SquishyFile compress the same file twice if I run it through the tool again?
Each run compresses whatever file you drop in at that moment — if that file is already a compressed export from a previous run, yes, that's a second pass. Keep your original source file around if you might need to compress it differently later.

What's the safest setting for a video I might need again later?
Light compression, and keep the original uncompressed file if you have the storage for it. You can always compress harder later if you need a smaller file; you can't get lost detail back once it's gone.

Can I visually tell how many times a video has been compressed?
Not precisely, but blockiness in flat areas, smeared fast motion, and a file size that's unusually small for the resolution and length are all signs of at least one prior pass — worth checking before you compress it again.


Need to compress a video right now without losing more detail than necessary? SquishyFile runs entirely in your browser — no uploads, no server round-trip, just drag, pick a level, and download.

Top comments (2)

Collapse
 
raknaos profile image
Raknaos

"The file was already compressed once" is the diagnosis most people miss, and the tell is the flattened gradient: the second pass spends bits reconstructing banding and blocking the first pass created, so the quality knob stops controlling what you think it does.

The escape I've used is to avoid the generation entirely rather than budget for it. For the usual "download a clip, trim it, send it on", a stream copy of the wanted range keeps the existing encode byte-identical and leaves one single lossy encode at the target. Same reason I stopped scaling screenshots through an intermediate size: downscale-upscale-downscale destroys text far faster than one resample.

One thing the piece implies without stating: is the damage additive regardless of target bitrate? I'd expect a second pass at the same CRF to look worse than its input even above the source bitrate, because CRF is a per-frame quality target, not a fidelity measure against the original.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.