Why a Compressed Image Gets Bigger and How to Fix It

You ran an image through a compressor or converter and the download is larger than the file you started with. In most cases that is not a bug: an encoder describes the pixels it is given in the format you asked for, and sometimes that description is longer than the one you had.

Short answer: the file grows when the new settings keep more than the old file did (a heavily compressed JPEG re-saved at higher quality), when a lossy photo moves into a lossless format (JPG to PNG), when the encoder drops a trick the original used (a palette PNG re-saved as 32-bit), when format overhead outweighs a tiny image, or when the pixel count goes up. In our tests a 135 kB JPEG became 2.21 MB as PNG, and a 504-byte icon became 1,104 bytes as WebP. The fix is usually to keep the original, pick another format or lower the quality; each section below says which.

The nine cases at a glance

Every number here comes from one run on our machine. Sizes are exact bytes; in the text, 1 kB means 1,000 bytes.

How we tested

We ran everything on 2026-10-16 (UTC) on an Apple M4 Mac with macOS 26.6.2.

• Browser encoders: Google Chrome 155.0.8059.85 in headless mode. We loaded browser-image-compression 2.0.2, the library behind our image compressor, into a blank local page and called it with the compressor's default settings: quality 0.8, a 1 MB size target, a 1920 px long-edge cap, the original format kept, EXIF removed and up to 30 retry passes. Converter cases used the same canvas calls as our converter pages: draw the image, fill white behind it for JPG, then canvas.toBlob at the converter's default quality of 90%. We did not click through the site itself; the code paths match, but the page around them was a test page.
• Other encoders: sharp 0.35.5 in Node v26.12.0 (libvips 8.18.7, mozjpeg, libwebp 1.6.0, libaom 3.15.1, libimagequant 2.4.1, libpng 1.6.58) and upng-js 2.1.0, the PNG/APNG encoder our GIF to APNG converter calls.
• Images: a CC0 landscape photo by Bonnie Moreland (Wikimedia Commons), taken from our compressor's output in an earlier benchmark (1920 x 1280, 250,382 bytes), plus a mozjpeg quality 70 re-encode of it (135,151 bytes); Kodak test image kodim04 (512 x 768 PNG, released by Kodak for unrestricted use); a screenshot of our own /compress page (1440 x 900 PNG); the CC0 "NEW LOGO R" by Enzy Cell (Wikimedia Commons) and a palette version of it; a 32 x 32 icon and a 12-frame GIF we drew for this test; and a 320 px wide thumbnail cut from kodim04.

Each figure is one run. The browser's PNG encoder is not byte-stable between runs, so expect small differences if you repeat this. We build ImgCompress.app, and the about page says who runs it. An AI assistant helped draft the text, and we checked every figure against the raw output files.

Why does re-compressing a JPEG make it bigger?

Because "quality 80" is not a fixed amount of compression. It is a setting for one encoder, and different encoders, or different quality numbers, keep different amounts of detail.

Our 135 kB test JPEG had been made with mozjpeg at quality 70, a setting tuned for small files. When Chrome's built-in encoder re-saved it at quality 80, it produced 168 kB, 24% larger. The browser decoded the JPEG into plain pixels, including the blocky compression noise mozjpeg had left behind, and then encoded those pixels with finer quantization than the original used. Nothing lost the first time comes back; the new file spends more bytes on the same picture plus the old artifacts.

The less-compressed version of the same photo, at 250,382 bytes, behaved differently. Chrome at quality 80 gave 250,670 bytes, only 288 bytes over. Re-saving with the same encoder and setting that made the file landed almost exactly on the original size.

What our compressor does about it

Our compressor checks the first result. In browser-image-compression, if the output is larger than the source (or above the size target), it re-encodes at 0.95 times the previous quality (0.85 for PNG) and keeps going until the file is under both limits or it runs out of passes. Dimensions only shrink in that loop when the file is above the size target, so a small photo keeps its pixel size.

For the 250 kB file, one extra pass at quality 0.76 brought it to 240,546 bytes, 3.9% smaller. For the 135 kB mozjpeg file, it took seven passes, down to quality 0.56, to get to 134,643 bytes. That is 508 bytes saved for a much lower quality setting on a file that was already compressed. When the result card shows a saving of a few percent or less, keep the original.

If the result is still not smaller and the format did not change, the compressor gives you the original file back, so it never hands you a larger file in the same format.

The longer explanation of quality numbers is in our JPEG compression guide.

Why is my PNG so much bigger after converting from JPG?

PNG is lossless. It stores every pixel exactly, and a decoded JPEG photo has a lot of pixels that differ slightly from their neighbours: film grain, sensor noise and the faint 8 x 8 block pattern that JPEG compression adds. A lossless format has to keep all of that.

The more aggressively the JPEG was compressed, the bigger the jump in our test, because the starting file was smaller while the PNG still had to store the same number of pixels. Converting to PNG also does not undo any JPEG damage. You get the same blur and blockiness, now stored without loss.

Convert JPG to PNG when you need PNG specifically: an editor that only accepts PNG, a master copy you will edit many times, or a form that rejects JPG. If the goal is a smaller file, stay with JPG or move to WebP or AVIF instead.

Why did my PNG grow when I re-saved it?

Two things in the browser work against you here.

First, Chrome's canvas PNG encoder packed the data far less tightly than the file it was given. Re-saving the kodim04 photo through canvas.toBlob turned 637,432 bytes into 846,413 bytes, 33% larger, with the same pixels. Even a careful lossless re-save does not automatically win: sharp with libpng at compression level 9 produced 638,304 bytes, 872 bytes more than the file we started with.

Second, a canvas holds every image as 32-bit RGBA, and that is what Chrome wrote out. A palette PNG stores each pixel as an index into a small colour table, which is how tools such as TinyPNG and pngquant get their small files. Our palette version of the logo was 45,525 bytes. Drawn on a canvas and saved again, it became 170,429 bytes, 3.7 times larger, because the colour table was gone and every pixel was stored in full.

Our compressor does not use plain canvas.toBlob for PNG. browser-image-compression passes the pixels to UPNG with a colour limit of 4096 times the quality, which is 3,276 colours at the default 0.8. Results from the same run:

This step reduces colours, so it is not lossless: the photo went from 31,716 distinct colours to 3,277, and the screenshot from 2,002 to 1,314. On already-optimized palette PNGs there is little left to gain, so re-compressing them through any tool, ours included, is mostly wasted effort.

Should a screenshot be saved as JPG?

Usually not. JPEG is designed for smooth photographic detail, and screenshots are flat colour with sharp edges around text. Chrome saved our JPG with 4:2:0 chroma subsampling, which stores colour at half the resolution of brightness in both directions; coloured text and thin coloured lines are where that shows first. In our 2x crop at quality 90, the difference from the PNG was hard to spot, but the file was still larger.

If a site insists on JPG, PNG to JPG at 80% got under the PNG size in our run, while 90% did not. Where WebP is accepted, PNG to WebP is the better swap for screenshots. A palette PNG made the smallest file of all, and we do not offer a 256-colour palette mode, so use a tool like pngquant or Squoosh when you need the last 50 kB. For the trade-offs between those two formats, see WebP vs PNG.

Why does WebP or AVIF come out larger than the original?

There are two separate reasons, and they appeared in two different tests.

Converting an already-compressed JPEG at a high quality

WebP and AVIF are often smaller than JPEG at equal visual quality. That comparison assumes you start from a clean source. Starting from a JPEG, the new encoder has to reproduce the JPEG's artifacts as if they were detail.

The 250 kB JPEG went from 250,382 to 269,556 bytes as WebP at quality 90, 7.7% larger. The quality number matters more than the format. When you use JPG to WebP, lower the slider from the 90% default and compare sizes, or try JPG to AVIF. Our AVIF deep dive covers what AVIF does to fine texture.

Tiny images and fixed overhead

Each format has fixed costs, such as headers and, for lossy WebP with transparency, a separately stored alpha channel. They weigh heavily when the whole image is 504 bytes.

Lossless WebP did beat the PNG by 140 bytes, but most choices made the icon bigger, including both AVIF settings. For icons and small UI graphics, keep the PNG, or use SVG if you have the vector source. In our tests, WebP and AVIF saved bytes on the photos, not on the icon.

Does resizing up or keeping metadata add bytes?

Enlarging adds bytes without adding detail. Our 320 x 480 thumbnail was 28,034 bytes. Re-saved at its own size at quality 80 it was 28,513 bytes; enlarged to 640 x 960 first, it was 62,114 bytes, 2.2 times larger for a softer picture. Our compressor never enlarges, because its 1920 px setting is a cap. A resizer will enlarge if you type larger numbers, so check the target size in the image resizer before you export. Resizing without losing quality explains why upscaling cannot recover detail.

Metadata was a small factor in our test. The thumbnail carried a Display P3 colour profile of 480 bytes and EXIF tags of 258 bytes, about 2.6% of its 28,290 bytes. Our compressor removes EXIF by default and keeps it only when you turn on "Preserve EXIF". Camera files can hold larger blocks, such as embedded preview images, so on small exports from a camera or phone, removing EXIF can matter more. It also removes the GPS location.

What happens when you convert a GIF?

GIF is old, but for a short animation with a few flat colours it is compact, because it stores palette indexes and can store only the part of each frame that changed. We drew a 12-frame, 240 x 240 animation of a dot moving across a plain background:

None of these changed the size much. This result covers only a small flat animation; we did not test long GIFs with photographic frames, where the 256-colour limit and dithering cost GIF more. For short flat animations, keeping the GIF is a reasonable choice, and if you need it smaller, the GIF compressor is the place to start.

What our tools do when the result is bigger

All of the processing above runs in your browser; on our site the image is not uploaded. What each tool does when the output grows:

• Compressor, original format kept: retries at lower quality while the file is larger than the source, then returns your original file if it still is not smaller.
• Compressor, format changed: you get the converted file even if it is larger. The result card lists both sizes, and the percentage appears only when the file got smaller, so compare the two numbers.
• Converters: encode once at the slider value (90% by default for lossy outputs) with no size check. Converting is about the format, so the size can go either way.
• Target size: while the file is above your target, each pass lowers the quality and, unless "Force original resolution" is on, shrinks width and height by 5%. After 30 passes it stops; a target it could not reach is flagged on the card.

Checklist before you re-compress or convert

1. Is the file already optimized? If it came from a CDN, a CMS or a tool like TinyPNG, a second pass usually saves little; ours saved 3.9% and 0.4%. Keep the original when the gain is that small.
2. Are you moving a photo into PNG? Only do it if PNG is required. Our two JPEGs grew 10.7x and 16.4x.
3. Is it a screenshot or flat graphic? Keep PNG or use WebP. JPG at 90% was larger than the PNG in our test.
4. Is it smaller than a few kB? Leave icons as PNG or SVG. WebP and AVIF headers can outweigh the pixels.
5. Did the pixel dimensions go up? Check the output size before saving. Enlarging doubled our thumbnail's bytes.
6. Is the converter at 90%? For JPG to WebP, try 75 to 80% and compare.
7. Do you need the metadata? Strip EXIF on small public images; keep it on photos you archive.

If you only want a smaller file in the same format, start with the compressor and compare the before and after sizes on the result card before you download.