Why did my file get bigger after converting it?

You converted a photograph to a lossless format

This is the cause perhaps four times in five. PNG and lossless WebP do not discard anything — they find repetition and encode it compactly. That works brilliantly on a logo, where thousands of pixels are the identical shade of blue, and barely at all on a photograph, where almost no two adjacent pixels match exactly. There is nothing repetitive to compress, so the file ends up close to the raw pixel data.

A twelve-megapixel photograph is around thirty-six million bytes uncompressed. As a JPG it might be three megabytes; as a PNG, fifteen or twenty. Converting the JPG to PNG therefore multiplies the size by five or more while adding no detail whatsoever — the PNG is a perfect, faithful, enormous copy of an image that was already lossy.

The fix is to go the other way. If the picture is a photograph and the destination is a screen, JPG or lossy WebP is the correct format, and the size drops back to where you expected.

The source was already compressed

Compression can only be done once usefully. An image that has already been through JPG has had its redundancy removed; re-encoding it does not find more. Worse, JPG artefacts themselves look like fine detail to the next encoder, so a second pass sometimes has to spend *more* bits preserving the damage from the first one.

The same applies to PDFs. A PDF assembled from JPG scans is already carrying compressed images, so running it through a compressor often achieves very little — and if that compressor re-encodes the images, the file can grow while the pages get visibly worse. There is no reduction left to extract because someone already extracted it.

The way to tell is to look at the input. If it arrived as a JPG, a WebP, an MP3 or a scanned PDF, it has already been compressed and you should expect single-digit percentage gains at best, not halving.

Quality was set higher than the original

A JPG saved at quality 95 will be larger than the same image saved at 80, even if the file you started from was itself an 80. The encoder does not know what quality the source used; it simply follows the number you gave it, spending bits to preserve everything it can see — including the compression artefacts already baked in.

This catches people who set quality to 100 believing it means "do not lose anything". It does not: JPG is lossy at every setting, so quality 100 discards a little detail *and* produces a very large file. It is the worst of both properties.

For an image already in JPG form, converting at 80 to 85 will usually shrink it. Converting at 95 will usually grow it. If you are unsure what the original used, start lower rather than higher — you cannot recover detail that is already gone, so protecting it costs size for nothing.

Transparency, colour depth and metadata

A few smaller causes worth knowing. An image with an alpha channel carries a fourth value for every pixel, so the same picture with transparency is meaningfully larger than one without. Converting an 8-bit image into a 16-bit format doubles the data per channel for precision no screen will display.

PNG also has an interlaced mode, which stores the image so it can render progressively while loading. It is a legacy of dial-up and it typically adds 20 to 30 percent for no benefit anyone still needs. Some editors leave it on by default.

Metadata is usually a small share but not always: an image carrying a full colour profile, a thumbnail preview and a long EXIF block can be surprisingly heavy at small pixel dimensions. Stripping it is worth doing for privacy reasons anyway, and occasionally it is most of the file.

The PDF cases that catch people out

Merging is the obvious one. Combining ten documents produces a file roughly the size of all ten together, because every page object comes across intact — merging is a container operation, not a compression one. People expect a merge to be smaller than the sum of its parts and are surprised when it is occasionally slightly larger, which happens when each source embedded its own subset of the same typeface and the merged file now carries several near-identical fonts.

Splitting can produce the same surprise in reverse. Extracting three pages from a two-hundred-page report usually yields a small file, because only the resources those pages reference come along. But if every page uses one large embedded font, a single-page extract still carries the whole font subset and looks disproportionately heavy for what it contains.

And a PDF made from images is bounded by those images. Assembling twenty phone photographs into a document produces a file a little larger than the twenty photographs, since a PDF structure is being wrapped around them. If that is too big, the answer is to resize the photographs before assembling rather than to compress the PDF afterwards — by then the decision has already been made.

Getting the reduction you actually wanted

Work out what the file is before choosing a format. Photograph, screenshot of a photograph, or video frame: JPG at 82, or lossy WebP if you control the destination. Logo, chart, diagram, screenshot containing text: keep it lossless, and if it is already PNG the size is probably correct rather than wrong.

Then check the dimensions, which people forget. A phone photograph is often 4000 pixels wide and being displayed at 800. Resizing the longest edge to what will actually be shown usually saves more than any amount of quality tuning, because file size scales with pixel count rather than with the quality slider.

And if the source is already compressed, accept the ceiling. The honest answer is sometimes that the file is already about as small as it sensibly gets, and the useful move is to reduce the dimensions rather than to keep re-encoding the same pixels and slowly degrading them.

Questions