Image Compressor

Width first, quality second

The two controls do not do the same kind of work. Quality decides how much of each block's detail the encoder throws away; the width cap decides how many blocks there are. Pixels scale with the square of the width, so halving the dimensions leaves a quarter of the data to encode, and that reduction arrives before the quality dial is touched at all:

4000 × 3000  =  12.0 megapixels     a phone photo, untouched
      2000 × 1500  =   3.0 megapixels     half the width, a quarter of the pixels
      1600 × 1200  =   1.9 megapixels     the usual web maximum

      12.0 -> 1.9 megapixels is 16% of the original data.
      The quality slider only affects what is left after that.

A page that shows a photograph at 800 pixels wide is paying for the other 3200 whenever it ships the original. Dropping the width costs nothing a visitor can see, because the pixels being removed were never going to be displayed — and it saves far more than any quality setting short of the point where the image falls apart. Reach for the slider only after the width is honest.

A second pass cannot cancel the first

Compression loss is cumulative rather than self-correcting. The second encoder starts from pixels that have already been rounded, and it has no way to tell your earlier loss from real detail — it quantises whatever it is handed, so the errors add up instead of washing out. Run the same file through at 60 twice and the second pass costs a generation of artefacts for a few percent of size, because most of what could be removed was removed the first time.

That makes the original the only good starting point. Edit from it, compress from it, and if a file has to go back and forth between tools, keep an uncompressed copy for the intermediate steps rather than a JPEG. PNG is lossless and will not add a generation, which is what an intermediate wants; it is a poor final format for a photograph, which is what the format control is for.

Flat areas fail first

A busy photograph has texture everywhere, and texture gives the encoder somewhere to hide the rounding — small errors land among detail that already looks like noise. A clear sky, a studio backdrop or a panel of one colour has nothing to hide behind, so the same rounding shows up as banding while the rest of the frame still looks untouched. That is why a setting that holds perfectly on one photo can fall apart on another at the same number.

Fine text and thin line art are the other end of it: they need the top of the range, because a single-pixel stroke has no redundancy left to sacrifice. The comparison slider is there for exactly this judgement, and where to drag it is not the middle. Put it over a face, a gradient sky, a pane of glass or a line of small text — the worst region in the frame, not the average one. If the two halves look the same there, they look the same everywhere.

What the encoder leaves behind

Decoding to pixels and re-encoding keeps the picture and drops the file. Exif blocks go, and with them the GPS coordinates, the camera body and lens, the shutter and aperture, and the timestamp — which is a small privacy win before a photo is posted anywhere public. The orientation tag goes too, and since it was the thing telling viewers the image was sideways, it has to be applied to the pixels before it is discarded. This page rotates first and resizes second, so a portrait photo comes out portrait rather than lying on its side.

A few things are lost without anyone intending them to be. An embedded colour profile is dropped unless it is sRGB, so an image in a wide gamut can come back looking flatter than it did. Sixteen bits per channel becomes eight. An animated image loses every frame but the first, because a canvas holds one. None of these are visible in the stat line, which is worth remembering before a file is replaced with its compressed version rather than kept alongside it.

When the picture is going to be published somewhere that accepts a modern format, WebP gets noticeably better results at the same byte budget, particularly around sharp edges and small text. If something downstream insists on JPEG, that is a reason to keep the JPEG, not a reason to re-encode the WebP. To pull the colours out of the photo before it goes up, the Colour Studio will read a palette straight off it.