Why Is My Converted Image Bigger Than the Original?

Why did the file get bigger?

You converted an image to make it easier to use, and the result is two, five, sometimes thirteen times the size of what you started with. The email bounces, the upload form says the limit is 2 MB, and the obvious question is what went wrong.

Usually nothing went wrong. Converting does not repackage the original file. It decodes the image back into raw pixels and compresses those pixels again, from scratch, with a different compressor and a different set of instructions. The new file’s size has almost nothing to do with the old file’s size. It depends on two things you chose, sometimes without noticing:

1. The format you converted to, and whether it throws anything away
2. The quality number the new file was written at

The four causes below are two of each, and each one has a fix.

How we measured

All the numbers here come from one run on 22 September 2026, in Chromium 151 on an Apple M3 Pro, using the browser’s own canvas encoder: the same one Chrome and Edge use for any in-browser converter. The photograph is the 1600x1067 image from this site’s About page, a detailed shot of leaves with a lot of fine texture, served as a 139 KB WebP. To have a JPG “original” to start from, we first saved it as a JPG at quality 75 (193 KB) and treated that as the file you downloaded. The screenshot is a 1280x800 capture of a plain settings page.

Cause 1: you converted a photograph to PNG

This is the big one, and it is where the thirteen-times figure comes from.

PNG is lossless by design. The specification’s own wording for its goal is that “filtering and compression should preserve all information”,[1] and it keeps that promise about every pixel it is handed. The trouble is what it is handed. A JPG is made of small blocks of approximated colour plus the faint noise that JPG compression leaves around edges, and to a lossless compressor that noise is information like any other. PNG stores all of it, exactly, at full cost.

So the PNG is not a higher-quality version of the photo. It is a perfect record of the JPG, artefacts included, and it cannot put back the detail the JPG already discarded. For a photograph that is going to be looked at, not edited further, JPG is the better output and the file will be a fraction of the size.

The exception runs the other way. On a screenshot, a diagram or a logo - large flat areas, sharp edges, few colours - PNG is the efficient format and JPG is the wasteful one:

The JPG at the default quality is bigger than the PNG it came from, and it is no sharper for the extra bytes. If the image is mostly text and flat colour, keep it as PNG, or go to WebP if the place it is going accepts WebP.

Cause 2: you went from a newer format to an older one

WebP and AVIF exist because they compress better than JPG. Google puts lossy WebP at 25-34% smaller than JPEG at an equivalent quality,[2] and AVIF is more efficient again. Converting to JPG gives that advantage back.

This one is the price of the conversion. You are trading size for a file that opens everywhere, which is the whole reason for converting a WebP in the first place. From AVIF the ratio is larger still: in our earlier measurement a JPG came out four to five times the size of the AVIF it replaced.

What you do control is how much of the gap you take, which is cause 3.

Cause 3: the quality number is higher than the original’s

The quality setting is an instruction to the encoder about how much to throw away on this save. The HTML standard describes it as “the desired quality level for the resulting image”.[3] It is not a measurement of the source, and the encoder has no idea the pixels it is being handed came from a quality 75 JPG. Ask it for 95 and it will spend the bytes to reproduce those pixels at 95, faithfully reproducing the blur and blockiness the 75 left behind:

Saving the 75 at 95 makes the file 63% larger and does not make it look any better, because there is nothing better to reproduce. Going lower than the original makes it smaller and slightly worse, since every lossy save loses a little more.

Most converters default high on purpose, because they cannot tell what the source was and a too-low default is a visible failure. Ours is one of them: the JPG default is 95, WebP 90. That is the right default for a download you intend to keep and the wrong one for a file you are about to email.

Cause 4: you set the quality to 100

In Chrome and Edge, quality 100 produces a different kind of file from 99.

One step on the slider, more than twice the size. The reason is a JPG feature called chroma subsampling: the encoder stores colour at half the resolution of brightness, because the eye is far less sensitive to fine colour detail than to fine light-and-dark detail. It is one of the main reasons JPGs are small. Chromium’s canvas encoder keeps subsampling on at every quality below 100 and turns it off only at exactly 100,[4] so at 100 the colour data doubles in resolution, and the file roughly doubles with it.

Firefox draws the line at 90 instead, and no standard says where it should be.[4] So the same slider position can produce very different files in two browsers.

There is one situation where 100 earns its size: a screenshot or graphic with coloured text, where subsampling smears the colour edges. For a photograph, 100 is almost all cost.

How do you get the size back down?

Five choices, roughly in the order worth trying them.

Pick the format by what is in the picture. Photographs go to JPG, or to WebP if the destination accepts it. Screenshots, diagrams and anything with text go to PNG. This one choice is the difference between 193 KB and 2.5 MB.

Drop the quality to 85. On our photograph, the WebP-to-JPG conversion went from 474 KB at 95 to 263 KB at 85, about a 45% cut, and the difference is something you have to hunt for at full size. In Save Image As Type this is the JPG Quality slider in Settings; it applies to every JPG save from then on, so move it back up if you want the next download at full quality.

Never use 100 for a photograph. 95 already keeps more than the eye can see on most images.

Shrink the dimensions if the file is too big for where it is going. A 4000 pixel wide photo attached to an email is mostly pixels nobody will see. Pixel count is the lever that no quality setting can replace: halve the width and height and there is a quarter of the image left to compress. The extension has a Resize section in Settings that caps saved images at a maximum width and height (1920x1080 unless you change it). It is off by default, and it only ever scales down.

Or do not convert at all. If you save a JPG as JPG, a PNG as PNG or a WebP as WebP, and nothing is being resized or edited, the extension skips the re-encode entirely and writes the original file with its metadata removed. So a same-format save comes out the same size or slightly smaller, and a lossy image does not go through its compressor a second time. The skip matters for PNG too: when we re-encoded our screenshot through the canvas instead, the PNG went from 59.7 KB to 88.4 KB with identical pixels, because the canvas compresses PNG less aggressively than the tool that made the original.

Which output will be smallest for your image?

A converted file’s size is set by the new format and the new settings, never inherited from the old file, so “why did it grow” is always answered by looking at what you asked the encoder for. If your conversion started from a WebP download that would not open, the WebP problem, end to end covers the rest of it, and the AVIF version covers the format where the size jump is steepest.