Why Your 'Compressed' Image Got Bigger, Not Smaller

It seems like it should be impossible: you run an image through a compression tool, expecting a smaller file, and somehow end up with something bigger than what you started with. It feels like a bug, but it’s almost always one of a handful of specific, explainable causes — and once you know what they are, they’re easy to avoid.

1. You converted from a more efficient format to a less efficient one

This is the single most common cause. Image formats vary a lot in how efficiently they compress the same content. WebP and AVIF generally compress photographic content more efficiently than JPG does; JPG compresses it far more efficiently than PNG does. If you “compress” an image by converting it from a more efficient format to a less efficient one — say, from WebP to PNG, or from AVIF to JPG — the file can easily end up larger than the original, even though you didn’t add any detail and the new file is, in some sense, “more compressed” within its own format’s terms.

This isn’t really compression failing; it’s a format conversion with a size cost that happens to run in the opposite direction from what you expected. It’s often still the right move if you needed the new format for compatibility reasons — you’re just trading file size for the ability to actually open or use the file somewhere the original format wouldn’t work.

2. The image was already heavily compressed, and you saved it as a lossless format

If you take an already-compressed JPG and convert it to PNG — perhaps because you wanted a lossless copy to edit — the resulting PNG is very likely to be larger than the JPG, often substantially. This is expected: PNG’s lossless compression doesn’t handle photographic detail efficiently, regardless of whether that detail is “original” or itself already the product of JPG’s lossy compression. You’re not recovering any lost quality by doing this (whatever the JPG already discarded is gone for good) — you’re just storing the same, already-degraded pixels in a less space-efficient way, deliberately, to stop further quality loss from accumulating if you’re about to edit the file further.

3. Your starting file was extremely small or simple to begin with

Compression algorithms — especially lossless ones, but to some extent lossy ones too — generally have a small amount of fixed overhead: header information, encoding tables, metadata. For an already-tiny or extremely simple image (a single-color icon a few pixels across, for instance), that overhead can occasionally exceed any savings the compression step would otherwise provide, leading to a “compressed” file that’s marginally larger than the uncompressed original. This is a real but fairly rare edge case, and it’s nothing to worry about for normal photos and graphics of typical size.

4. You ran lossy compression on an image that was already optimally compressed

If an image has already been compressed efficiently — by the device or software that originally created it — running it through another round of “compression” sometimes produces a result that’s barely smaller, or in some cases very slightly larger, particularly if the second tool uses different encoder settings or a different version of the same algorithm than the first one did. This is uncommon with significant size differences but does happen with already well-optimized images, especially ones a professional tool or service already processed carefully.

5. Re-encoding added metadata the original didn’t have

Some image processing tools add metadata on save — color profile information, software version tags, sometimes thumbnail previews embedded in the file — that the original file didn’t include. For a very small image, this metadata overhead can occasionally be large enough relative to the image data itself to produce a slightly bigger file, even though the actual visual compression worked as expected.

How to tell which one happened to you

Check two things: did the file format change, and was the original already compressed? If you converted formats (especially toward a less size-efficient one like PNG), that’s almost certainly the explanation, and it’s expected behavior rather than a malfunction. If the format stayed the same and the file still grew, it’s more likely related to the original already being efficiently compressed, or — for very small or simple images — fixed encoding overhead exceeding the available savings.

The actual fix, if file size is your real goal

If your priority is genuinely the smallest possible file, rather than a specific format for compatibility or editing reasons, make sure you’re compressing toward a format suited to your content (JPG or WebP for photos, PNG or lossless WebP for graphics needing transparency or sharp edges) and avoid round-tripping through a less efficient lossless format unless you specifically need losslessness for further editing. Going PNG → JPG for a photo will reliably shrink things; going JPG → PNG for the same photo will reliably do the opposite, and that’s not a bug in either direction — it’s just two formats doing exactly what they’re designed to do.