My file got bigger after compressing. How is that possible?

Because the compressor still has to write its own bookkeeping — a header, a dictionary, framing around the data — and if it finds no redundancy to remove, that bookkeeping is pure addition. It is the normal outcome on data that is already compressed or genuinely random, and it is a signal rather than a fault: the file was already at or near its floor. Keep the original and move on to a structural change.

Does this mean lossless compression is weak?

No — it means it is honest. On data with real redundancy it is very effective: a database dump, a log file or a text-heavy PDF can lose a large fraction of its size without a single bit of information changing. What it will not do is invent room where there is none, and it will not degrade your document to produce a better-looking number. On anything you may have to defend later — a filing, a signed contract, an original scan — that is the property you actually want.

Is generation loss visible after just one re-save?

Rarely, at a sensible quality setting and if nothing else changed. It becomes visible when the re-saves accumulate, when the quality setting is low, or when the image is also resized between saves — resizing forces a full re-encode and interacts badly with existing block artefacts. The safe habit is not to count passes but to avoid the situation: keep the original, and produce each output you need from it directly rather than from the last thing you exported.

Why does the same tool save 40% on one PDF and 2% on another?

Because the saving depends entirely on how much redundancy the file was carrying, and that varies enormously with how it was made. A PDF exported repeatedly from an editor, or generated by a template system that repeats a definition on every page, is full of removable duplication. A PDF written once by a well-behaved library, or one that is essentially a stack of photographs, has almost none. The percentage is a fact about the file's history, not a rating of the tool.

Should I use a stronger archiver on top, like 7-Zip?

Only on data that has not been compressed yet. A stronger archiver has a better model and will beat a weaker one on text, source code, databases and raw exports — sometimes substantially. On a PDF, JPEG, MP3 or MP4 it is working on data that is already near its floor, and the gain will be a percent or two for the cost of a container the recipient has to unpack. Use the strong archiver where the redundancy lives, not on files that have already had theirs removed.

Why Compressing a File Twice Does Not Halve It Twice

Published 6/26/2026 · 10 min read · File tools

Daniel Okonkwo — Front-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 4 sources

View profile →

In short

Compression does not squeeze a file the way a press squeezes a bale, where more pressure always yields more. It finds structure that can be described more briefly and rewrites it — and once the structure is gone, there is none left to find. Lossless compression is therefore close to idempotent: running it a second time finds a file whose redundancy has already been removed and returns it essentially unchanged, sometimes a few bytes larger because a new header has been added. This is not a defect. It is what "lossless" means: the first pass already removed everything removable without discarding information, so a second pass has no legal move. There is a hard floor underneath it, Shannon's entropy of the data, and no algorithm gets below it — which is also why zipping an already-compressed PDF, JPEG or MP4 gains one or two percent at best. Lossy compression behaves differently and worse. Each pass discards real information and re-encodes what remains, so a second pass does shrink the file further, but it does so by throwing away detail that the first pass had already thinned, and the damage accumulates while the gains shrink. That is generation loss: a JPEG saved five times at quality 75 is visibly degraded, while a JPEG saved once at quality 45 is smaller and looks better. The practical rule follows from both halves. Run a lossless tool once and believe its result. If you need a lossy file smaller, go back to the original and use a stronger setting once — never re-compress the compressed copy.

The first pass takes 30% off and the second takes nothing. That is not a broken tool — it is the difference between removing redundancy and removing information, and knowing which one you are doing tells you when to stop and what a second attempt actually costs.

Compression removes redundancy, not volume

The mental image most people carry is mechanical: the file is a sponge, the tool squeezes it, and squeezing harder or twice gets more out. That picture predicts a second pass should help, and it is wrong about what the machine is doing. A compressor looks for patterns — a byte sequence that already appeared, a colour repeated across a region, a dictionary entry that can stand in for a long word — and replaces each occurrence with a shorter reference. What comes out is not the same data pressed smaller. It is a different, briefer description of the same data.

Once that rewrite has happened, the repetitions are references and the references do not repeat. A second compressor arrives at a file that looks, statistically, like noise — which is exactly what well-compressed data looks like — and finds nothing to shorten. It still has to write its own header and framing, so the output is occasionally a hair larger than the input. A tool that reports zero or a negative saving on the second run is not failing; it is reporting the truth about a file that has already been done.

There is a floor, and it has a name

In 1948 Claude Shannon showed that any body of data has a minimum size below which no lossless method can take it. That minimum is its entropy: a measure of how much of the data is genuinely unpredictable. A page of English text is highly predictable — after "th" an "e" is very likely — so it compresses well. A stream of random numbers is not predictable at all, so it does not compress, and no future algorithm will change that. Compression tools are not competing to squeeze harder; they are competing to model the data better and get closer to a limit that is already fixed.

This is why the familiar experiment of zipping a PDF gains nothing worth having. The PDF's internal streams are already deflate-compressed and its images are already JPEGs; the file is close to its entropy, and the zip has nothing to work with. The same is true of an MP4, an MP3 and a PNG. If a file type ends in a format designed to be small, assume the compression has been done and that a general-purpose archiver will add packaging rather than remove bulk.

Lossy is a different machine with a different failure

Lossy compression is not bound by entropy, because it does not have to reproduce the original. It decides what a person will not notice — fine colour variation, high-frequency detail, sounds masked by louder sounds — and discards it. That is why a JPEG is a tenth the size of the raw image it came from, and why the second pass behaves so differently: there is always more to discard, so the file always gets smaller, and the question shifts from "can it?" to "at what cost?".

The cost is generation loss, and it compounds in a way that surprises people. Every re-encode starts by decoding the previous result, which already contains the artefacts the previous pass introduced. The new pass treats those artefacts as real detail worth preserving, spends bits on them, and adds its own. Five saves at a good quality setting produce visibly worse output — blocking around edges, colour smearing, a general muddiness — than one save at a much lower quality setting that reaches the same file size. The rule that follows is the only one that matters in practice: always compress from the original, never from a compressed copy.

Which one is a given tool doing?

The behaviour tells you. A lossless tool gives a modest, repeatable saving on the first run and roughly zero on the second, and its output is pixel-identical to the input. A lossy tool offers a quality slider or presets — light, medium, strong — and keeps producing smaller files as you push it. If a tool takes a scanned PDF from 20 MB to 3 MB, it is re-encoding the images and it is lossy, whatever the button says. The compressor on this site is the first kind: it rewrites the PDF's object structure and leaves every image byte untouched, so it will never give you a dramatic number on a scan, and it will never quietly degrade a document you are about to file somewhere official.

The one case where a second pass genuinely helps

Running the same algorithm twice is pointless. Running a different one on the same original is not. A stronger method with a better model of the data — a modern archiver rather than a classic one, or a newer image format instead of an older one — can beat the first result, because it is a better attempt at the same limit rather than a second attempt at an already-solved problem. Re-encoding a JPEG as AVIF or WebP from the original file typically lands smaller at matched quality; re-zipping a zip does not.

Two practical consequences. Keep originals: once you have only the compressed copy, every future improvement in formats is closed to you, because you can no longer compress from something undamaged. And when a file is stubbornly too big after one honest pass, stop reaching for the compressor and change something structural instead — fewer pages, lower resolution, a shorter clip, a split into two files. Those are decisions about content, and content is where the remaining bytes actually are.

What to do instead of pressing the button again

Run the lossless pass once and take the number it gives you as the truth about that file. If it is not enough, identify where the bytes are before doing anything else: in a PDF, divide size by pages; in a video, multiply duration by bitrate; in an image, look at the pixel dimensions. Then act on that specific thing once, from the original. Two decisions made deliberately beat five passes made hopefully, and they leave you with a file that is smaller and has not been through the mill five times.

What a second pass does, by kind of compression
Behaviour	Lossless — structure	Lossy — images, audio, video
First pass	A real saving, typically modest and repeatable	A large saving — often 80% or more from raw
Second pass	≈ 0%, occasionally a few bytes larger	Smaller again, but the damage accumulates
Is the output identical to the input?	Yes, bit for bit	No — detail is discarded on purpose
Hard limit	Shannon entropy — no method goes below it	None — only what remains acceptable to look at
If it is still too big	Change the content: fewer pages, split the file	Go back to the original and use a stronger setting once

Compress PDFShrink a PDF without losing anything: identical fonts and images repeated by a merge are merged back into one. A whole folder at once.Try the tool →

Frequently asked questions

My file got bigger after compressing. How is that possible?: Because the compressor still has to write its own bookkeeping — a header, a dictionary, framing around the data — and if it finds no redundancy to remove, that bookkeeping is pure addition. It is the normal outcome on data that is already compressed or genuinely random, and it is a signal rather than a fault: the file was already at or near its floor. Keep the original and move on to a structural change.
Does this mean lossless compression is weak?: No — it means it is honest. On data with real redundancy it is very effective: a database dump, a log file or a text-heavy PDF can lose a large fraction of its size without a single bit of information changing. What it will not do is invent room where there is none, and it will not degrade your document to produce a better-looking number. On anything you may have to defend later — a filing, a signed contract, an original scan — that is the property you actually want.
Is generation loss visible after just one re-save?: Rarely, at a sensible quality setting and if nothing else changed. It becomes visible when the re-saves accumulate, when the quality setting is low, or when the image is also resized between saves — resizing forces a full re-encode and interacts badly with existing block artefacts. The safe habit is not to count passes but to avoid the situation: keep the original, and produce each output you need from it directly rather than from the last thing you exported.
Why does the same tool save 40% on one PDF and 2% on another?: Because the saving depends entirely on how much redundancy the file was carrying, and that varies enormously with how it was made. A PDF exported repeatedly from an editor, or generated by a template system that repeats a definition on every page, is full of removable duplication. A PDF written once by a well-behaved library, or one that is essentially a stack of photographs, has almost none. The percentage is a fact about the file's history, not a rating of the tool.
Should I use a stronger archiver on top, like 7-Zip?: Only on data that has not been compressed yet. A stronger archiver has a better model and will beat a weaker one on text, source code, databases and raw exports — sometimes substantially. On a PDF, JPEG, MP3 or MP4 it is working on data that is already near its floor, and the gain will be a percent or two for the cost of a container the recipient has to unpack. Use the strong archiver where the redundancy lives, not on files that have already had theirs removed.

Articles you may find interesting

All guides →

How-toSplitting a File That Is Too Big to SendThe last resort when nothing can be compressed further. It works, and it has three sharp edges: the parts are useless on their own, the order is absolute, and the megabyte you set is not the megabyte the limit means.GuidePull the Plug: Which Online File Tools Actually Upload Your DocumentEvery online file tool promises your document is safe. Almost none tell you whether it leaves your machine at all. There is a five-second test that settles it without reading a single privacy policy, and it works on any tool — including this one.How-toPhotographing a Document and Getting a PDF That Is AcceptedNobody owns a scanner any more, so the phone does it. Two things decide whether the result is accepted: how you took the photograph, and what page size it becomes. The second one surprises people, because a photograph turned into a PDF is not A4 unless something makes it A4.How-toGetting a PDF Under a 10 MB Upload LimitThe form rejects your file and offers no advice. What works depends entirely on where the megabytes actually are, and for a scanned document the answer is not compression at all — it is resolution. Here is how to tell which case you have in ten seconds.GuideWhat a PDF Says About You: Reading and Clearing Its MetadataA PDF carries its metadata twice, in two stores that can tell different stories, and neither of them is the whole story. Here is what is actually in the file, what clearing it removes, and the two things that survive every wipe.How-toTurning Notes into a PDF Worth ArchivingPlain text has no layout, so any converter has to invent one for you. Here is exactly which decisions this one makes — page, margins, font, line breaks — what it does with a tab and a long line, and what you have to add yourself before a note is worth keeping.

Retention windows and processing models are what each service published on the dates cited. They change without notice — re-run the offline test on any tool you rely on rather than trusting a comparison, including this one.

Sources

Spotted a mistake in this article?