Why Are PNG Files So Big? The Byte Math

Why are PNG files so big? Because PNG is a lossless format: it stores every pixel exactly and never throws data away, the way JPEG does. High color depth, up to 32 bits per pixel once you add transparency, photographic content that resists prediction, large pixel dimensions, and extra metadata or interlacing all stack on top of that lossless floor and push the size higher.

I build the PNG compressor on this site, so this is not a guess about what the format does to your bytes, it is the arithmetic behind it. PNG explained covers the format broadly: color modes, transparency, the full compression story. This page does one narrower job. It walks through exactly what inflates a PNG, with the numbers filled in, so you know which lever to pull before you reach for a compressor.

Why are PNG files so big? The short answer

PNG files are big because lossless compression is not allowed to discard anything: every pixel is preserved exactly, so the format cannot cheat the way a lossy codec can. That is a feature for a logo or a screenshot, where you want every edge crisp, and a liability for a photograph, where a lossy format would drop detail your eye never registers and save you most of the file.

The honest one-line version: a PNG is large in direct proportion to how much unique visual information it holds, times the number of bytes each pixel is allowed to cost. Flatten either of those, fewer distinct colors or fewer pixels, and the file drops. The rest of this page is those two numbers, made concrete.

What makes one PNG bigger than another?

Two numbers multiply against each other: how many bytes each pixel costs before compression, and how well filtering and DEFLATE can shrink that raw total afterward. Most oversized PNGs lose on one of the two, and often on both at once.

Bits per pixel: the cost before compression starts

A truecolor PNG with alpha spends 4 bytes on every pixel, one each for red, green, blue, and transparency, before any compression runs. An indexed, palette-based PNG spends as little as 1 byte per pixel. That gap compounds fast across real image sizes.

Every number there is before filtering or DEFLATE touches the file. A PNG saved as truecolor when an indexed palette would have done the same job is paying for 4 bytes a pixel it never needed. Truecolor uses 24 bits per pixel, 32 with alpha, and 16-bit-per-channel files double that again to 48 or 64 bits, which is why high bit depth is one of the classic size drivers.

Color mode alone accounts for most of the raw difference. Take the web banner from the table, 1200 by 628 pixels, and look at what each color mode costs before any compression algorithm runs:

Dropping that banner from truecolor with alpha to an 8-bit palette cuts the raw byte cost by 75 percent before filtering or DEFLATE do a thing. Color depth, not the compression algorithm, is usually where the size is hiding.

Dimensions: every extra pixel is more bytes

The other multiplier is raw pixel count, and it scales linearly. A 4000 by 3000 photo holds 12 million pixels; the same shot at 1200 by 900 holds 1.08 million, which is 91 percent fewer. Because every pixel costs its bytes-per-pixel before compression even starts, trimming the dimensions is often the single biggest reduction available, ahead of any encoder setting. If a PNG is physically larger than it will ever be displayed, a logo saved at 5000 by 5000 for a 200-pixel slot, resizing it down is the first move, not compression. You cannot filter away pixels the file is still being asked to store.

Photographic noise defeats the filters

A photograph resists PNG's compression in a way a logo never does, and this is the second half of the size problem. On a screenshot or a flat graphic, whole rows of pixels repeat, so the format has long stretches of sameness to collapse. A photo carries sensor noise in every pixel, so almost nothing repeats. That is the same phone photo that comes back 60 to 80 percent smaller as a JPEG barely shrinking at all as a PNG, because a lossless format cannot discard the noise a lossy one throws away. For the full split between the two families and when to reach for each, see lossy versus lossless compression.

How does PNG compression actually work?

PNG compresses in two stages, both lossless: first a per-row filter rewrites each pixel as the difference from a predicted value, then DEFLATE, the same LZ77-plus-Huffman method used in zip files, packs those differences (PNG format overview). Nothing is discarded, which is the whole point and also the whole cost.

The five filter types, None, Sub, Up, Average, and Paeth, each predict a pixel from a different neighbor, and a good encoder picks the best one per row. When neighboring pixels are identical or change smoothly, the filtered differences cluster near zero, and near-zero runs are exactly what DEFLATE compresses best. That is why a flat brand color or a gradient shrinks dramatically while a noisy photo barely moves. The algorithm is not weaker on the photo. The photo hands it nothing repeatable to work with.

A concrete case makes it clear. Take a row of 200 identical white pixels. The Sub filter stores the first pixel, then the difference from each previous pixel, which is zero, 199 times over, and DEFLATE turns that run of zeros into a handful of bytes. Swap in a row of a photo's sky, where each pixel differs slightly from the last: the differences are small but never zero, so the same 200 pixels cost many times more. Same filter, same encoder, wildly different output, decided entirely by the picture.

This is also why the same encoder produces different results on different content with the identical settings. Filtering plus DEFLATE is a bet that your image has structure it can predict. Graphics, text, and screenshots pay that bet off; photographs do not.

Why is a photo so much bigger as a PNG than a JPEG?

Because JPEG is allowed to throw away detail and PNG is not. JPEG uses lossy compression tuned for photographs, discarding high-frequency information your eye barely registers to reach roughly a 10 to 1 reduction (JPEG overview). PNG keeps every pixel, so on a photo it commonly lands 5 to 10 times larger than the same image as a JPEG.

That is the png vs jpeg file size gap in one line: PNG is the right tool for flat graphics and the wrong tool for photos. WebP splits the difference, since for photographs a lossy WebP is typically 25 to 35 percent smaller than the matching JPEG (choosing an image format). If your oversized PNG is a photograph, the format is the problem, not the settings, and PNG vs JPG covers exactly when to keep one over the other.

Does metadata make PNG files bigger?

Yes, and sometimes by a surprising amount. Ancillary chunks, the optional metadata blocks a PNG can carry, ride along whenever an editor writes them: color profiles, text fields, timestamps, and in some tools an entire embedded thumbnail. None of it changes how the image looks, and none of it is free.

Photoshop is the repeat offender. Exporting a PNG the old way can attach a chunk recording the document's editing ancestry, and forum threads regularly show the same image ballooning to many times its expected size from embedded metadata that has nothing to do with the pixels. The fix is exporting without the extra data, or stripping it afterward with a tool that removes ancillary chunks.

Color profiles are the other quiet addition. An embedded ICC profile describes exactly how the file's colors should be interpreted, which matters for print work and rarely for a web graphic, yet many editors attach one by default. On a small graphic that profile can be a meaningful fraction of the whole file. Stripping it, when you do not need color-managed output, is free size back with no visible change.

The invisible-layers myth

A common belief is that hidden or invisible layers inflate a PNG. They do not. PNG has no concept of layers at all, so the layer count in your editor cannot affect the exported PNG's size directly. What actually happens is that a layered, complex document tends to carry more embedded metadata, and in some export paths gets flattened to full truecolor even when a palette would do. The layers are a symptom, not the cause. The bytes come from color depth and metadata, every time.

Interlacing

Interlacing reorders pixel data so a browser can show a rough preview before the file finishes loading. It breaks up the row-to-row patterns filtering depends on, and it usually costs file size rather than saving it. Leave it off unless a progressive preview genuinely matters to you.

How do you tell why your own PNG is big?

Check four things in order, and one of them almost always explains it. First, the pixel dimensions: if the image is far larger than where it will actually be shown, that is your answer, and a resize fixes it. Second, the content: a photograph living in a PNG is a size problem no setting will fix, only a format change will. Third, the color mode and bit depth: a truecolor or 16-bit file holding what a 256-color palette could show is spending bytes it does not need. Fourth, metadata: an unexpectedly heavy file with modest dimensions and few colors is usually carrying embedded chunks, a color profile, or a thumbnail.

Run through those four and the oversized PNG stops being a mystery. Most image tools will show you the dimensions and, on export, the color mode; the lossless re-encode a good compressor performs will also show how many bytes were padding versus real image data, which tells you fast whether the file was saved carelessly or is genuinely carrying that much picture.

When is a big PNG actually the right PNG?

Sometimes the size is correct and shrinking it is the wrong move. If the content genuinely needs every pixel, a large PNG is doing its job.

A screenshot attached to a bug report needs every pixel exact, so trading fidelity for bytes defeats the purpose. Line art and scanned documents with genuinely fine detail can hold more real information than a flat logo, and quantizing them down to 256 colors will visibly band the image. High bit-depth PNGs, 16 bits per channel instead of 8, exist for print and scientific work where the extra precision is the whole reason someone chose PNG. In each case the honest answer is not a smaller PNG, it is confirming you actually need a PNG. If the content is a photograph and none of those constraints apply, converting to JPEG or WebP will beat any amount of PNG optimization.

How do you make a PNG smaller?

Pull three levers, roughly in order of payoff: quantize to a palette, strip metadata, and skip interlacing. To reduce PNG file size without touching a single pixel's final color, all three change only how efficiently the pixels are packed, not the picture itself.

Quantize to a palette, the biggest win

Converting truecolor to an optimized set of up to 256 colors is the largest single saving available. The palette-quantization tool pngquant does exactly this, and can cut a real, already-compressed PNG by as much as 70 percent while keeping full alpha transparency intact (pngquant). It is the same lever the raw-byte table pointed at: color depth, not the algorithm, is usually where the size is hiding.

Strip metadata and run a lossless optimizer

Removing ancillary chunks a browser never reads costs nothing visually. A lossless optimizer like oxipng re-packs the DEFLATE stream at a higher effort level and can strip metadata in the same pass (oxipng). Our own PNG path stays strictly lossless, it repacks whichever colors you keep and strips metadata by default, so if you want both the palette saving and the lossless repack on one file, run it through the PNG compressor and pair it with a quantizer.

When to switch formats instead

If the file is a photograph, stop optimizing the PNG and change the format. A photo will almost always be far smaller as a JPEG or WebP, and no amount of lossless PNG tuning closes that gap. This is the one case where the fix is not a smaller PNG at all.