ShrinkToKB

How image compression actually works (and how we hit exact KB targets)

Most compression tools are a black box: slider in, mystery file out. This guide opens the box — partly because it’s genuinely interesting, and partly because understanding it makes every “compress to N KB” task predictable instead of trial-and-error.

What “quality” actually controls

A JPEG encoder doesn’t store pixels. It slices the image into 8×8 blocks, converts each block into frequencies — broad gradients (low frequency) versus fine texture (high frequency) — and then rounds off the high-frequency numbers. The quality setting controls how aggressive that rounding is.

Rounding fine texture works because human eyes are excellent at seeing shapes and edges but poor at tracking subtle texture. At quality 85, the rounding stays below what most people can notice. At quality 30, flat areas turn into visible smudgy plateaus and edges grow faint ripples (“artifacts”).

Two consequences fall straight out of this design:

  1. Detailed images cost more bytes. A face against a white wall is mostly low-frequency — cheap. A crowd scene or foliage is high-frequency everywhere — expensive. The same quality setting can produce a 40 KB file from one photo and a 400 KB file from another at identical dimensions.
  2. You can’t ask for a size directly. The encoder’s only input is quality; the file size is an outcome, discovered after encoding. No formula predicts it exactly.

So how do you hit “just under 50 KB”?

You search for it. Since size increases with quality, the relationship is monotonic — and monotonic functions can be binary-searched:

  1. Encode at the highest quality (0.95). Under target? Done — maximum quality fits.
  2. Encode at the lowest acceptable quality. Still over target? Quality alone can’t get there (more on that below).
  3. Otherwise, repeatedly encode at the midpoint of the current range, keeping the half that still brackets the target. Seven rounds narrows the range to under 1% of the dial.

The result: the highest quality whose output fits under your byte limit — not an approximation, and never over.

Doing this server-side would mean seven round-trips of your photo, which is why upload-based tools don’t do it. Locally, seven encodes of a form-sized photo take well under a second — the search only became free when the compression moved into the browser.

When quality alone can’t reach the target

A 4000-pixel-wide photo at even the ugliest JPEG quality may still exceed 20 KB — there are simply too many pixels to describe. At that point the honest move is reducing dimensions: halving width and height quarters the pixel count, and bytes track pixel count roughly linearly at a fixed quality.

Our tool estimates the needed scale from the miss distance (specifically, the square root of target ÷ achieved, with a safety margin), resizes, and re-runs the quality search. One or two rounds typically suffice. This mirrors what upload forms expect: portals demanding 20 KB photos also expect small dimensions — see resize vs compress for that relationship.

Why PNG plays by different rules

PNG is lossless: it compresses by finding repetition (runs of identical pixels, repeating patterns), never by discarding. There is no quality dial to search. Flat-color graphics shrink dramatically; photographs — where almost no two pixels repeat exactly — barely shrink at all. That’s why “compress PNG to 50 KB” really means resizing, and why photos should travel as JPEG or WebP instead (the format guide has the full decision table).

Practical takeaways

The whole pipeline — decode, search, resize if needed, final encode — runs in your browser’s canvas API on your own hardware. No queue, no upload, and the privacy claim holds by construction rather than by promise.