Why a Converted Image Gets Bigger, Measured

The floor and the ceiling: pixels times bytes

Every raster picture has a fixed ceiling, the uncompressed size: width x height x 3 bytes for ordinary color. A 1920 x 1080 picture is 2,073,600 pixels, so 6,220,800 bytes. A 4000 x 3000 phone photo is 12,000,000 pixels and 36,000,000 bytes. Compressed formats land somewhere beneath that ceiling, and the position depends on the format and the content.

BMP sits on the ceiling. My 1920 x 1080 BMP was 6,220,854 bytes: the 6,220,800 pixel bytes plus a 54-byte header. (BMP pads each row to a multiple of four bytes; 1920 x 3 = 5,760 already is one, but a picture 1001 pixels wide has rows of 3,003 bytes padded to 3,004.) So converting almost anything to BMP makes it far bigger, by design.

How the test pictures were made

I generated two synthetic 1920 x 1080 pictures. Picture A is flat color blocks with lines of text, like a screenshot. Picture B is smooth gradients and blurred shapes with fine noise, a stand-in for a photo. Everything below was encoded with Pillow 12 (its libjpeg and libwebp builds). Browsers use their own encoders, and real photos sit somewhere between my two pictures, so treat the byte counts as illustrations of direction and rough scale, never as typical results.

Six conversions, counted

Each row starts from one picture and shows the size after a conversion. The JPEG at quality 85 was made from the original, then converted onward.

Conversion	Picture A bytes	Picture B bytes
Original as PNG	135,263	3,587,826
PNG to JPEG, quality 90	219,783	330,904
Original to JPEG, quality 85	190,580	226,395
That JPEG to PNG	482,158	1,993,234
That JPEG to WebP, quality 80	80,450	61,900
That JPEG to BMP	6,220,854	6,220,854

Read the table by columns of surprise. Picture A grew when it went from PNG to JPEG (+62 percent), which is the opposite of the usual rule. Both pictures grew when a JPEG became a PNG (2.5 times and 8.8 times). And BMP ignored the content entirely.

Why a JPEG turned into PNG balloons

PNG stores the decoded pixels exactly, including every flaw JPEG added. Those flaws, speckle around edges and block patterns, are small irregular variations that PNG cannot predict from neighboring pixels, so they cost real bytes. Picture A makes it obvious: the clean original was 135,263 bytes as PNG, but the PNG made from its JPEG was 482,158, 3.6 times larger, because the JPEG had sprinkled noise around every letter.

Picture B shows the reverse side. Its clean PNG was 3.59 MB, mostly the fine noise I added; the JPEG removed much of that noise, so the PNG made from the JPEG was 1.99 MB, smaller than the original PNG though still 8.8 times the JPEG. Same conversion, opposite relation to the original PNG, because what counts is how predictable the pixels are. The effect is explained step by step in lossy vs lossless, and when this conversion is justified in converting JPG to PNG.

When PNG to JPEG gets bigger, and when a JPEG regrows

PNG to JPEG shrinks photographs but can enlarge flat graphics. Picture A went from 135,263 to 219,783 bytes because JPEG describes each hard edge with many coefficients while PNG describes a flat run with almost nothing. A screenshot, a chart or a scanned page of text should usually stay PNG; see JPEG vs PNG.

A second trap hits files that are already compressed. I saved each picture as JPEG at quality 60, then re-encoded that result at quality 90, hoping for a better one. Picture A grew from 134,939 to 207,706 bytes (+54 percent), and Picture B from 80,860 to 132,409 (+64 percent), with no gain in detail, since the data was already gone. Re-encoding at quality 100 was worse: 315,700 and 361,646 bytes. The size shown after conversion reflects the settings you chose, not the amount of information in the picture.

The high-quality setting trap

Quality 100 does not mean exact; it means fine rounding, and it costs. On Picture B, JPEG at quality 100 was 1,534,583 bytes against 330,904 at quality 90, 4.6 times more. On Picture A the quality 100 file was 397,835 bytes, nearly three times its PNG. How the slider behaves and where to stop is covered in image quality after converting.

Reading the before and after sizes, with a scenario

The change in percent is (new - old) / old. A file that goes from 3.1 MB to 27 MB is +771 percent, and anything above zero is growth. Here is a hypothetical case with numbers borrowed from my noisy test picture. Say you have a 4000 x 3000 JPEG of 3.1 MB (raw size 36,000,000 bytes, so the JPEG holds 8.6 percent of that). A form wants PNG. Picture B's JPEG-to-PNG jump was 8.8 times; if your photo behaves similarly, the PNG lands in the tens of megabytes, which no 5 MB upload field will take. I cannot give a precise figure, since real photos vary, but the order of magnitude is the point: a JPEG source makes a PNG that is many times larger.

One more small effect: the PNG writer matters. Pillow's default PNG of Picture A was 135,263 bytes and with its optimize option 129,962, about 4 percent less; Picture B went from 3,587,826 to 3,441,443, also about 4 percent. A browser's built-in PNG encoder is not necessarily tuned for the smallest output, so a PNG made in a browser may be a few percent larger than one from a dedicated optimizer. That is a small effect next to the 2x to 9x jumps above.

Getting the size down: what to try, in order

1. Check the direction of the conversion. If you went from JPEG to PNG or BMP, the growth is expected; stay with JPEG if the destination allows it.
2. Reduce pixel dimensions. Halving each side leaves a quarter of the pixels. Picture B at 960 x 540 and quality 90 was 64,294 bytes, 81 percent below the full-size 330,904. For a picture that will only be seen on a phone screen, the removed pixels were never visible. The converter's maximum-size option does this.
3. Then lower the quality a little. Steps from 90 to 80 save the most for the least visible change.
4. Try WebP if the destination accepts it. Smaller than JPEG for similar looks, usually, but only where the browser offers WebP output (Safari does not) and the destination accepts it.
5. If the new file is still larger than the original, keep the original format. The original was probably well optimized, and the result list puts both sizes side by side, which exposes it at once.