I compressed my image and the file got bigger

2026-08-24

You drop a 480 KB JPG into a compressor, wait for it to finish, and the result is 512 KB. Not smaller. Bigger. It feels like the tool is broken, or lying, or both.

It is neither. Compressing an image that was already compressed well is a real situation with a real explanation, and the interesting question is not why it happens but what the tool should do about it.

What a browser-side compressor actually does

It cannot edit your file in place. The only thing a browser can do is decode your image into raw pixels — a plain grid of red, green, blue and alpha values, with no compression left in it at all — and then encode a brand new file from that grid.

The word to sit with is new. The output is not your file made smaller. It is a different file that happens to look the same. And every decision the original encoder made is gone by the time the re-encode starts, because those decisions lived in the compressed data, not in the pixels.

Reason 1 — your original was encoded better than a browser can

A JPEG is not one fixed recipe. The encoder that produced your file chose quantisation tables, chroma subsampling and scan layout, and dedicated encoders spend real effort on those choices. Photoshop's "save for web", an image CDN, and a command-line optimiser all squeeze harder than a generic encoder does.

A browser exposes exactly one lever: a quality number. Everything else is whatever the browser's built-in encoder does by default. If your file came out of a tool that optimised it properly, a browser re-encode at any quality can easily land above where it started — not because the browser is bad, but because it is playing with fewer pieces.

Reason 2 — the PNG case, where it gets dramatic

PNG has a mode called indexed colour: instead of storing a full colour for every pixel, the file stores a palette of up to 256 colours and then one small index per pixel. For a logo, an icon or a screenshot, that is roughly a quarter of the data of full-colour PNG, and good exporters use it automatically.

Now decode that file. The palette dissolves — every pixel becomes a full 32-bit RGBA value, because that is the only thing raw pixels can be. Re-encode from there and you get a full-colour PNG, four bytes per pixel, from a file that used to spend about one. A 300 KB icon can come back as 1 MB, and nothing went wrong.

This is the specific problem PixelSquish solves by rebuilding a palette on the way out — median-cut colour selection with error-diffusion dithering, done in your browser — rather than handing back the 32-bit version. On browsers that can't run it, the encode falls back to the plain path instead of failing.

Reason 3 — asking for more quality than the original had

This one is the most counter-intuitive. Suppose your file was saved at quality 60, and you compress it at 90.

Quality 60 left visible artifacts in the pixels: blocking, ringing, softened edges. Those artifacts are the image now — the decoder has no idea they were ever damage. So a quality-90 encode dutifully spends bytes preserving them in fine detail. You are paying, at high fidelity, to store the previous encoder's mistakes.

The general rule: re-encoding above the original's quality adds bytes without adding anything you can see. Our slider defaults to 82, which sits below most camera and export defaults for exactly this reason.

What the tool should do — and what ours does

A compressor that hands you a bigger file has failed at its one job. So there is a floor. If all of the following are true, PixelSquish throws its own output away and gives you back your original file untouched:

• the dimensions did not change,
• the format did not change,
• the image itself was not altered, and
• the new file came out the same size or larger.

You get a line that says "Already well optimised — kept the original". That is not a fallback for an error. It is the correct answer to "make this smaller" when the honest answer is "it already is". The same guard runs in batch editing, where it had originally been missed.

Where we deliberately let the file grow

The floor only applies when the picture is genuinely unchanged. In four cases a bigger result is the correct result, so it is allowed through:

• Resize and crop — you asked for different pixels. If enlarging produces a larger file, that is the outcome you requested, not a failure.
• Watermark — the image now has something on it that wasn't there.
• Background removal — the output carries an alpha channel the input never had. Transparency costs bytes.
• Rotate and flip — same size, different picture, so the original is not a valid substitute.

Converting to PNG belongs in the same category. PNG is lossless and stores transparency, so a JPG photo converted to PNG will usually be several times bigger. When the result runs well past the original, the tool says so and points you back toward JPG if you don't need transparency.

When it grows anyway, we show it

If a result does end up larger — in one of the cases above, or in a batch — the size is labelled with a red +N% badge instead of being quietly folded into a total that still reads like a saving. A number that looks like a win when it isn't is the one thing a compressor really cannot afford.

The short version

• Compressors decode to raw pixels and encode a new file. Your original encoder's work does not survive that trip.
• Well-optimised JPGs and indexed PNGs are the usual growth cases, and neither means the tool is broken.
• Don't re-encode above the original's quality — you'll spend bytes preserving old artifacts.
• If nothing about the image changed and the output isn't smaller, you should get your original back, and be told that plainly.