Why a resized PNG sometimes comes out bigger
Shrinking a PNG removes pixels, so the file should shrink with them. When it grows instead, the pixel format changed underneath, and the arithmetic explains why.
You take a screenshot 3000 pixels wide, ask a resizer for 800, and the file that comes back is larger than the one you started with. The pixel count fell by a factor of about fourteen and the bytes went up. Nothing has gone wrong. The arithmetic of an image file is not the arithmetic of a pixel grid, and the space between those two is where this happens.
A file on disk is not the picture. It is a set of instructions for rebuilding the picture, and the cost of those instructions depends on how varied the pixels are, not on how many there are. Fewer pixels carrying more colours is routinely a bigger file than more pixels carrying fewer.
Fewer pixels, more colours
Start with the raw counts, because they show why the surprise is reasonable. A 3000 × 2000 screenshot holds 6,000,000 pixels. At 800 pixels wide the same picture is 800 × 533, which is 426,400. Whatever the image holds per pixel, there are now about a fourteenth as many pixels to hold it. On pixel count alone the resized version should be smaller, and on most photographs it is.
What changes underneath is how much each remaining pixel costs to describe. Store a pixel as an index into a table of 256 colours and it costs one byte. Store it as three numbers, one each for red, green and blue, and it costs three. Add a fourth for transparency and it costs four. That is the whole of the explanation for most of these cases: the per-pixel price tripled or quadrupled the moment the resampler ran, and twelve times fewer pixels cannot pay for that.
6,000,000 pixels × 1 byte per pixel = 6,000,000 bytes (indexed, 3000 × 2000)
426,400 pixels × 4 bytes per pixel = 1,705,600 bytes (RGBA, 800 × 533)The raw pixel data still went down, from roughly 5.7 MiB to roughly 1.6 MiB, before either file is compressed. The file grew anyway, so the compression stage lost more than the pixel stage saved. It usually did, because the flat fill the palette was representing so cheaply stopped being flat.
The palette was carrying the file
This is the cause that catches almost everyone, and it begins with a decision made long before you resized anything. Screenshots, logos, icons and charts are pictures with few distinct colours. When one of those is saved, the encoder can notice that the picture uses a few dozen of them and write a colour table — the palette — followed by one byte per pixel, each byte naming a row in the table. The specification calls that an indexed image, eight bits per pixel. A flat interface stays small in that form because it is mostly runs of the same byte repeated, and DEFLATE eats runs of identical bytes for breakfast.
Now resize it. The resampler does not move whole pixels around; it computes each new pixel as a weighted average of the source pixels it overlaps. Every new pixel near an edge — a glyph outline, a panel border, a drop shadow — is a blend of two or more source colours, and that blend was not in the table. There is no entry in a 256-row palette for it. The encoder has one move: promote the image to truecolour, twenty-four bits per pixel, or to truecolour with alpha at thirty-two if there is transparency to carry.
The promotion happens in the file header, before a single byte of pixel data is compressed, and it is not optional. A blended pixel cannot be held in a palette that does not contain it. The resized file therefore starts three or four times heavier per pixel than the original, and the compressor has to earn that back out of content that has turned from flat runs into shallow gradients. Sometimes it manages. When it does not, the file is bigger, and the resizer did exactly what you asked.
And an alpha channel that was not there
A resampled edge is not only a colour problem. If the original had a hard edge against transparency — a rounded icon corner, a wordmark on a clear background — each new pixel along that edge is a mixture of the shape and of nothing at all. The resampler expresses that mixture as a partly transparent pixel, and that pixel needs the fourth number. An opaque twenty-four-bit source resized without care comes back thirty-two-bit, and the extra byte per pixel lands on every pixel, blended or not.
What is in the channel matters as much as the channel. An alpha channel that is opaque everywhere compresses to nothing, because constant data is what DEFLATE is for. One with a single anti-aliased ring around a shape compresses badly, because it repeats nowhere. A logo that sat at a few kilobytes as an opaque palette PNG can come back at several times that, purely as a ring of blended pixels that did not exist before.
The filter and the compression level are chosen per image
PNG does not compress pixels directly. It filters them first, one row at a time, subtracting what a neighbouring pixel or the row above already predicted. Five filters are available — None, Sub, Up, Average and Paeth — and the choice is made per row, because a row that repeats the one above it is best encoded as nothing at all. The encoder tries the candidates and keeps whichever gives the smallest sum of absolute differences, a cheap proxy for what DEFLATE will do with the result.
That heuristic is tuned against typical content, and downscaled content is not typical. A flat interface row is one value end to end, so the filter choice barely matters. A resampled row is a series of small steps, and the gap between a good choice and a mediocre one is a real percentage of the output rather than a rounding error. Encoders left on a fast or default setting — most of them, including an export from a browser canvas — sample the choice roughly and move on.
The compression level works the same way. Level 1 searches a short distance back for repeated strings; level 9 searches further and tries harder before giving up on a match. On flat content the difference is small, because the matches are long and obvious. On resampled content, where repeats are short and irregular, the expensive search finds matches the cheap pass never looked for. It is the cheapest thing to try before you decide the tool is broken.
Interpolation invents pixels
The honest summary of a smooth downscale is that it makes up data. Interpolation produces intermediate colours so the result reads as the same picture at a smaller size, and every one of those colours has to be stored exactly, because PNG is lossless. The original had a run of two hundred pixels of one exact grey. The resized version has a run of greys all within a percent of each other and almost none of them equal, and DEFLATE is much less good at a sequence where every byte differs from the one before it than at a long identical run.
That is why nearest-neighbour behaves so differently. It picks the closest source pixel instead of averaging, so no new colours appear, the palette survives, the output stays indexed and the file stays small. It also leaves a jagged, aliased edge on anything with a diagonal or a curve, and on small text it looks visibly worse than a smooth version a few kilobytes heavier. Palette survival is the trade you accept, and it is a real trade rather than a free win.
Metadata, and the chunk nobody looks at
Sometimes the pixel data is not the culprit. A PNG carries chunks besides the pixels: an iCCP chunk holding a colour profile, sRGB and gAMA chunks recording how the stored values should be read, cHRM for primaries and white point. A full display profile can run to tens of kilobytes, and one can appear without your asking, because export dialogs attach one and a re-encode sometimes writes one where the original carried only an sRGB chunk. Dropping a profile the original carried moves the number equally far the other way.
This is the least common cause and the easiest to rule out, because it is visible in the file rather than inferred from it. Compare the chunk listings of the two files and look at what sits outside the image data — the IHDR, the IDAT and the IEND. If one file carries a large iCCP chunk and the other does not, you have your answer.
What you did, what changed, what to do
| What you did | What changed underneath | What to do |
|---|---|---|
| Screenshot saved as a palette PNG | Blended edge pixels had no palette entry, so the encoder promoted the file to truecolour before compressing anything | Compress the original at its own size, or convert the resized file to WebP and compare |
| Logo on a transparent background | Anti-aliased edges needed partial alpha, so the result is thirty-two-bit where the source was twenty-four | Convert to WebP, or re-export the artwork at the target size rather than resizing a bitmap |
| Photograph saved as PNG | The flat runs the format was living on were removed by interpolation; the container was wrong from the start | Convert to JPEG or WebP. No compression level will make a photographic PNG small |
| Resize at the default compression level | Per-row filter choices and the DEFLATE level were picked for speed on typical content, not on resampled content | Re-encode at the highest compression level and compare. Expect a few percent, not a rescue |
| Re-encode through another tool | An ICC profile or colour chunk was written over the original's, or one the original carried was dropped | Compare the chunk lists in both files. Strip metadata or change format rather than resizing again |
Read down the middle column, which is the only one that changes, and name the thing the resizer did that the file could not absorb. The right-hand column is deliberately dull, because the fix is rarely a different setting on the same operation.
What to do with the file you have
There are two honest routes out, and which one you take depends on what the source was. If the original is a palette image — a screenshot, a logo, a chart — its small size was a property of its flatness, and that property holds only while the pixels stay on the grid they were drawn on. Compressing it harder at its original dimensions is a real win and costs nothing but an encode. If you need the smaller dimensions, you are producing a different kind of image, and that deserves a different format.
The second route is usually the answer, so it is worth stating without hedging: convert the resized image to WebP, or to JPEG if the picture is photographic and nothing in it needs to be transparent. Lossless WebP on a resized screenshot frequently lands under the original PNG while keeping every pixel exact; lossy WebP at a sensible quality goes far lower, and on interface imagery the artifacts show on text before they show anywhere else. A photograph in a PNG was never going to be small at any size, because DEFLATE has nothing to bite on in continuous tone, so converting it is the whole of the fix.
The comparison to make is against the original file, not against an ideal. The question is not whether the resized PNG could be smaller in principle — it cannot be, once its pixels stopped being members of a palette. The question is whether the file you now hold, in a format that suits what it has become, is smaller than the file you started with and still shows what it needs to show.
Where the tools fit. Run the experiment on your own file rather than taking any of this on trust. The Image Resizer shows the output size for the dimensions you ask for, and the Image Compressor works on the compression side at the original dimensions. Resize the file, note the number, then compress the original and compare the two figures.
If the resized PNG is larger than the source, run it through a converter as well and compare all three. The pattern is consistent enough that one file will teach you the rest.
The check I run
Take any PNG and look at its twenty-sixth byte. The first eight bytes are the signature, and after the header's width, height and bit depth comes the colour type: two for truecolour, three for indexed, six for truecolour with alpha. Do that for the original and for the resized result. If the colour type moved from three to two, or from two to six, you have found the cause.
The rule of thumb that follows: a PNG that grew under a downscale was almost never resized badly. Its pixels stopped being flat, or it gained a channel, or it fell out of its palette, and the encoder had to describe a harder image with fewer pixels to do it in. So the useful move is not to resize again at a different setting. It is to ask whether the picture should still be a PNG at all, and to answer that against the file you started with.