PNG on a photograph, or JPEG on flat graphics

PNG is a lossless format. It was built to reproduce logos, screenshots, UI mockups, and line art pixel-for-pixel, which is exactly why a PNG of a text-heavy screenshot looks crisp and stays small. Point that same lossless engine at a photograph — a sunset with thousands of subtly shifting colors, a portrait with skin-tone gradients — and it has almost nothing to throw away. Every one of those millions of unique color values has to be stored somewhere, so the file stays heavy no matter how hard the compressor works.

Run the same photo through a compressor that treats it as a PNG and you might shave 10–15% off the size. Convert that identical photo to JPEG or WebP first, and it’s common to see an 80–90% reduction with no visible difference on screen. The format decision, not the compression setting, is doing most of the work here.

You compressed a 4000×3000 photo that displays at 800×600

Compression and resizing are two different operations, and a lot of people assume a “compress” button does both. It usually doesn’t. If your phone shoots a 12-megapixel photo and you upload that untouched file to a blog post where it displays at 800 pixels wide, you’re storing roughly fifteen times more pixel data than the page will ever show. A compressor can squeeze the encoding of those pixels, but it isn’t going to delete pixels you never asked it to remove — that’s a separate step, and skipping it is the single biggest reason a “compressed” file still feels enormous.

This is easy to miss because the image still looks identical in a browser tab — the browser is scaling it down visually while your server still has to send every original pixel over the wire.

EXIF, XMP, GPS coordinates, and embedded thumbnails

Every photo your phone or camera takes carries a small file-within-a-file of metadata: camera model, lens, shutter speed, GPS coordinates, timestamps, sometimes even an embedded preview thumbnail baked in by the editing software that last touched it. None of that data affects how the image looks. All of it adds bytes — anywhere from a few kilobytes to well over a hundred kilobytes on files that have passed through several editing apps, each one appending its own metadata block on save.

On a large photo this metadata might only be 1–2% of the total size, which is why stripping it alone rarely “fixes” a big file. But on a smaller graphic, or when it’s stacked on top of the other issues on this list, it’s often the difference that keeps a file from crossing a size threshold you’re trying to hit.

Adobe RGB or ProPhoto RGB instead of sRGB

Photos exported from professional editing software are often tagged with a wide-gamut color profile like Adobe RGB or ProPhoto RGB, which can add anywhere from 50 KB to over 200 KB to the file, versus roughly 3 KB for the standard sRGB profile that every browser and screen actually uses for web display. Outside of print production, that extra color data is invisible to the person viewing the image online — their monitor is rendering in sRGB regardless of what profile is attached.

This one is sneaky because it shows up disproportionately on images exported from Photoshop, Lightroom, or a professional camera’s raw converter, which is exactly the workflow a lot of small business owners and photographers use for their website images.

Busy scenes resist compression more than simple ones

Two photos taken on the same walk, at the same resolution, on the same phone, can land at wildly different file sizes — and it has nothing to do with settings. A clean shot of open sky or a plain wall compresses beautifully because there’s very little the algorithm needs to describe: large areas of near-identical pixels collapse down easily. A crowded market scene with hundreds of overlapping textures, fine detail, and sharp edges gives the compressor far less redundancy to exploit, so it has to keep more information to avoid visible artifacting.

If you’re comparing two “similarly sized” photos and wondering why one compresses to 900 KB and the other refuses to go below 3 MB at the same quality setting, this is usually why. It’s not a bug — it’s the content.

Some compressors never touch the actual pixel data

Not every tool that says “compress” is doing the same job. Lossless PNG optimizers work by reorganizing the file’s internal structure and squeezing out redundancy in how the data is packed — they never discard a single pixel value. That’s genuinely useful and completely safe, but it typically only recovers 10–30% of the file size, because there simply isn’t much slack to remove without changing the actual image.

If you need a much bigger reduction than that, you need lossy compression — a process that selectively discards visual information a viewer won’t notice — or a format switch entirely. Expecting lossless-only results to match what lossy compression can do is comparing two different tools doing two different jobs.

There’s a floor, and you might already be near it

Once a JPEG has been through a real compression pass, running it through a compressor again won’t meaningfully shrink it further — most of the redundancy the algorithm knows how to exploit is already gone. Each additional round mostly just re-encodes data that’s already near its practical minimum for that quality level, sometimes adding new artifacting on top for barely any size gain. The visible symptom is exactly what prompted this article: you run the tool, it finishes, and the number barely moves.

This is also why “compress it again to make it smaller” rarely works the way people hope. It’s not that the second pass fails — it’s that there’s very little left to compress.

90–95% quality barely compresses anything

Most people leave a compression tool’s quality slider wherever it defaults to, assuming “high quality” and “well compressed” are the same setting. They aren’t. Above roughly 90% quality, JPEG and WebP encoders are preserving almost all of the original detail, which means file size drops very little compared to the uncompressed source. The visually meaningful savings — the range where file size drops sharply with no perceptible quality loss to an average viewer — tends to sit between 70% and 85% for most photographic content.

If a tool’s default is set conservatively (some are, to avoid customer complaints about quality), you can run image after image through it and keep seeing underwhelming results, purely because the setting itself was never in the range where compression does its heaviest lifting.

A setting most people never see, quietly working against them

Human eyes are far more sensitive to differences in brightness than to differences in color, which is why JPEG and WebP encoders normally store color information at a lower resolution than brightness information — a technique called chroma subsampling, usually written as 4:2:0. It cuts a meaningful chunk of file size with essentially no visible cost on ordinary photographs.

Some editing software, and some export presets, disable this and encode at full color resolution (4:4:4) instead — useful for images with fine colored text or thin colored lines, but unnecessary overhead on a typical photo. If a photo is stubbornly larger than a visually similar one, and you’re exporting through desktop software rather than a simple web-based compressor, this setting is worth checking.

BMP, uncompressed TIFF, and high-color GIF can’t shrink much

A handful of formats simply weren’t designed to be small. BMP typically stores raw, uncompressed pixel data. TIFF often does the same unless a compression flag is explicitly set. GIF, when used for a photo instead of simple graphics, is limited to 256 colors and has to dither continuous tones to approximate them, which bloats the file even though it’s technically “compressed.” Running any of these through a general compressor might recover a modest amount, but you’re working against the format’s own architecture, not just a setting.