Resized Photo Bigger Than the Original? Why

A resized photo gets bigger when the tool saves it at a higher JPG quality setting than the original was saved at. File size depends on two things: how many pixels there are and how hard the encoder compresses them. Fewer pixels usually win, but a high quality setting can cancel that out. Phone and web photos are often saved at a moderate quality. If you resize one and export at 90% or more, the encoder keeps detail the first save already threw away, and it has to store all of it again. We measured this on a test photo, and the numbers below show how far it goes. The fix is to match the quality setting to the source, or to resize less and compress after.

We built a 4000 x 3000 test photo with gradients, shapes and light noise, saved it as a JPG at 60% quality (738 KB), then resized it the way our resizer does: Chromium canvas, JPG output at 92%. At 75% of the width the result was 1,373 KB, 86% bigger than the original with 44% fewer pixels. At 50% it was 626 KB, about 15% smaller. Only at 25% (156 KB) did the saving look like what you expect. Same file saved at the original's 60% instead: 357 KB at 75%, and 155 KB at 50%. This is a synthetic image, so treat the exact percentages as a demonstration, not a promise. Real photos have less noise, so your gap will usually be smaller, but the direction is the same.

JPG is lossy. The first save at 60% discards fine detail and stores what is left in coarse steps. When you resize, the new pixels are blended from neighbours, so the picture has fresh smooth tones and soft edges. Saving that at 92% tells the encoder to preserve those blends precisely, in much finer steps than the original used. You pay for precision that was never in the photo. Quality is also not a percentage of the original size. 92% means finer rounding, not 92% of the bytes. So the same image can be several times larger at 92% than at 60%, and a modest pixel cut will not make up for that.

The resize tool exports JPG at 92% quality unless you move the Quality slider, whatever quality the source had. That default is right for a photo that was saved at high quality, because the result does not get visibly worse. It is wrong for a file that was already compressed hard: you can end up with a bigger file and no visible gain. Our test shows the break-even. A source saved at 92% shrank at every size we tried (3,456 KB down to 1,580 KB at 75%). A source at 80% stayed about the same at 75% scale (1,516 KB to 1,490 KB). Below 80% the default can grow the file. Lower the slider to roughly the source's level, or just try 70 to 85 and compare.

First, check what you are comparing. Look at the file size of the original JPG, not the camera's raw file or a PNG screenshot, since a PNG changes the picture completely (see our guide on why PNG to JPG can get bigger). Second, drop the Quality slider before exporting: 75 to 85 is a sensible range for photos on the web. Third, if the result is still larger, resize by a bigger step; the saving grows quickly below half the width. Fourth, run the result through the compressor if you need a hard size target. Finally, resize from the best copy you have. Resizing a copy that was already resized and re-saved stacks losses without shrinking anything.

Less common causes are worth ruling out. Converting a JPG to PNG or WebP at the same time changes the format, and PNG is almost always larger for photos. Enlarging instead of shrinking adds pixels, so the file grows by definition. Metadata is rarely the cause: EXIF is tiny next to image data, as covered in our note on whether resizing removes EXIF. Animated files behave differently, since a GIF stores every frame (see why resizing a GIF can increase its size). If none of these fit, compare the quality setting first, because it explains most of the cases.