Why the same image comes back 4x smaller from one tool than another

A designer sent me two versions of the same product shot. Hers was 840 KB. Mine, after running it through a different tool, was 190 KB. Side by side on a laptop screen, I could not tell them apart.

That gap is not one tool being "better at compression." It comes from four separate decisions, and most tools make them silently. Once you know what the four are, you can tell whether a tool is optimizing or just quietly throwing away quality you did not agree to lose.

1. Format beats parameters, by a lot

This is the one people skip, and it dominates everything else.

• PNG is lossless. Great for screenshots, icons, flat color, anything needing transparency. Storing photographs in it is the most common waste — photos have almost no repeating pixel patterns, so lossless has nothing to grab onto.
• JPEG is lossy and built for photographs. No transparency, and hard edges on text pick up ringing artifacts.
• WebP lands roughly 25–35% under JPEG at comparable quality, and it supports transparency.
• AVIF goes smaller still, but encodes slowly and older software may refuse to open it.

So if tool A hands you back a WebP when you fed it a PNG, of course its output is dramatically smaller. That is not a better algorithm. That is a different event.

Before you compare two tools, check what container came back:

// drop this in the console after downloading both files
const buf = new Uint8Array(await file.arrayBuffer());
const sig = [...buf.slice(0, 12)].map(b => b.toString(16).padStart(2, '0')).join('');
// 89504e47 → PNG   ffd8ff → JPEG
// 52494646 ... 57454250 → RIFF….WEBP
console.log(sig);

If the signatures differ, the size comparison is meaningless and everything below is moot.

2. Quality 100 is not "safe," it is expensive

Every lossy encoder exposes a quality knob, usually 0–100. The reflex is to drag it to 95 or 100 and feel responsible about it.

Above roughly 85, file size climbs steeply while the visible difference collapses. A quality-100 JPEG can be more than twice the size of the same image at 85, and putting them side by side at 200% zoom, most people cannot call which is which.

The part that actually matters: the best quality point depends on what is in the picture.

A tool that classifies the image first and then suggests a value is doing real work. A tool that applies one number to everything is not.

3. The most underrated move: change the dimensions

This usually beats parameter tuning outright, and almost nobody does it first.

Phone cameras happily produce 4000×3000. The place you are about to put that image — a chat thread, a doc, a web page — often renders it at 800 px wide. Every pixel beyond that is pure overhead, and size scales with area: halve the longest edge and you land near a quarter of the bytes.

So the order is: decide the display size, resize to it, then argue about quality. Tuning quality on a 4000-pixel-wide image is effort spent in the wrong place.

Rough targets that hold up in practice: 1500 px for chat, under 1200 px for in-article web images, 800 px for document figures.

4. The bytes you cannot see

A photo straight off a phone carries more than pixels:

• EXIF — capture time, camera model, exposure settings, GPS coordinates
• ICC profile — sometimes hundreds of KB on its own
• Embedded thumbnail — a second, smaller copy of the image
• Depth and HDR gain maps — newer phones write these routinely

Together these can run to tens or hundreds of KB. Some tools strip all of it and post an instant win. Others preserve everything.

There is a privacy edge to this one. EXIF GPS records where the photo was taken. Posting an original straight to the web can publish your home address alongside it. Most social platforms strip EXIF on upload — but not all of them, and files you send through cloud storage, forums, or email usually keep it intact.

// crude check: does the file still carry an EXIF block?
const head = new Uint8Array(await file.slice(0, 65536).arrayBuffer());
const hasExif = [...head].some((b, i) =>
  b === 0x45 && head[i+1] === 0x78 && head[i+2] === 0x69 && head[i+3] === 0x66); // "Exif"
console.log(hasExif ? 'metadata still present' : 'stripped');

Even lossless has room

PNG output varies between tools too, which surprises people who read "lossless" as "only one possible result."

PNG lets the encoder pick a row filter per scanline, and a good encoder tries several and keeps the best. Separately, reducing a truecolor image to a 256-color palette is technically lossy, but for icons, screenshots, and UI elements the difference is usually invisible while the file drops to roughly a third.

That palette step is where implementations diverge hardest. Same 256 colors on paper — but how the palette is chosen, and how precisely each pixel maps into it, decides whether you get clean output or banding and muddy patches.

How to catch a tool degrading your image quietly

Smaller is not automatically better. Four checks:

Did the format change? You uploaded PNG. Is the download still PNG? A silent switch to JPEG turns transparency into black or white.

Did the dimensions change? Some tools cap the longest edge by default and never mention it.

Zoom in on the failure-prone areas. Text edges, smooth gradients, dark regions. Blurry glyphs, ringed banding across a sky, blocky patches in shadows — all signs of overcompression.

Does it tell you where processing happens? On your machine, or on their server? A serious tool states this outright. To verify, open DevTools → Network, process an image, and watch what moves. You should see codecs being downloaded to you, not your image going out.

That last check is what pushed me toward ImgIng for everyday work. Common-format conversion and compression run locally in the browser with no upload request for the image itself, and the interface marks which capabilities are local versus which go server-side — HEIC writing and some professional formats still require an upload, and it says so rather than hiding it. That is a claim you can confirm in thirty seconds with the Network panel, which is worth more than any assurance in a marketing page.

The short version

When the same image comes out four times smaller somewhere else, it is usually a combination of:

1. Format changed — the largest single factor; confirm you are comparing like with like
2. Different quality target — returns collapse above 85, and the sweet spot moves with content type
3. Dimensions changed — the most effective and most overlooked; half the edge, a quarter of the bytes
4. Metadata stripped — EXIF, ICC, thumbnails; also a privacy question

Working order: size first, then format, then quality. Reversed, most of the effort goes where the returns are smallest.