Quality Sliders Are Wrong: Target-First Image Compression

You've been here: an upload form that rejects files over 100 KB, an avatar field that silently downsamples whatever you give it, an email client that refuses to attach the screenshot. The workflow almost every developer defaults to looks like this — export at JPEG quality 80, check the file size, too big; export at 60, check, small enough but blurry; try 70. Repeat until you run out of patience.

That loop is not your fault. It's the tooling's fault: the quality slider is the wrong primitive for the job. This post is about why, and about a better primitive — target-first compression — that flips the inputs and searches for the highest quality that fits your size budget. It all happens in the browser, which is why your images never have to leave your machine.

Why the quality slider is the wrong primitive

A quality slider asks you to control a means (encoder settings) when what you actually care about is an end (file size plus visual quality). Three things make the slider a bad handle:

The numbers are meaningless across encoders. Quality 75 in MozJPEG, quality 75 in Photoshop's "Save for Web," and quality 75 in canvas.toBlob are three different things. The scale isn't standardized, so a number you memorized in one tool doesn't transfer to another.

The quality-to-bytes curve is image-dependent and non-linear. The same q60 that produces a 22 KB flat-color illustration can produce a 400 KB noisy photograph. Texture, gradients, and noise change the output size far more than the slider position does. There is no setting you can learn once and reuse.

Undershooting wastes quality. If the limit is 100 KB and q70 gives you 58 KB, you've left quality on the table — the budget had slack for a better-looking image and you didn't take it. Guess-and-check converges on "good enough" far more often than it converges on "best possible."

The insight is that a size budget is a constraint, and a compression setting is a search result. Once you frame it that way, the right interface is obvious: state the budget, and let the encoder search for the highest quality that satisfies it.

Target-first compression: state the budget, search the quality

Instead of asking "what quality setting should I use?", you ask "what's the file size limit?" — 100 KB for an upload form, 25 KB for an avatar, whatever the constraint is. The compressor then runs an encode-measure-adjust loop: try a high-quality encode, measure the bytes, and if it's over budget, step the quality down and try again, keeping the best result that fits.

It's a small search problem, and the economics work out in the browser. A single canvas.toBlob encode on a typical web image takes milliseconds, so even a half-dozen encode passes complete before you'd notice. The result card tells you the actual output size, so verification is built in — no more exporting, checking, and re-exporting.

The quality difference is real precisely because of the undershoot problem above. When the search stops at the first quality that fits rather than at a number you guessed, it reliably lands closer to the budget, which means better fidelity for the same bytes.

Client-side encoding, and why privacy is structural

The search loop is built on ordinary web APIs — canvas, toBlob with a quality parameter, typed-array measurement of the output. Everything runs locally in your page's JavaScript context.

That locality is the whole privacy story, and it's worth stating plainly: when compression happens in the browser, the image bytes never touch a server. There's no upload queue to trust, no retention policy to audit, no terms-of-service ambiguity about what a compressor might do with your screenshot — and screenshots are exactly the kind of file that tends to contain API keys, customer data, or unreleased product UI. Privacy here isn't a policy promise; it's an architectural fact. If there's no network call, there's nothing to leak.

This is also why the workflow is fast in the boring, reliable way: no round trip, no waiting room, no "processing on our servers" spinner. Drag, drop, done.

The one-click workflow

The Compress Image to 100KB tool at ToolkitLoop implements exactly this target-first flow:

1. Set your size budget — a KB target like 100 KB, whatever the constraint is.
2. Drop in the image — drag and drop, or paste straight from the clipboard (screenshots included).
3. Let the browser search — it tries higher-quality encodes and keeps the best one that fits the budget.
4. Read the result card — it shows the actual output size, so you can confirm it landed under the limit.

It handles JPG, PNG, and WebP. It's free, no sign-up, and the processing stays on your machine as described above.

Where target-first doesn't apply

Honesty requires the limits. Target-first compression optimizes quality per byte budget — it doesn't resize dimensions, so if you need exactly 1200×628, resize first and compress second. It works the encoder's lossy settings, so don't expect miracles from an already-tiny file: a 12 KB flat icon has nowhere to go. And format choice still matters — if your pipeline is WebP everywhere, encode to WebP; the search finds the best quality within your budget for the format you chose.

Also worth knowing: compression is a one-way function. Always compress from the original, never from an already-compressed copy, or you're stacking artifacts on artifacts. The search finds the best quality for this budget from this input — give it the best input you have.

The takeaway

Stop tuning the slider. The number on a quality slider is an implementation detail of a specific encoder on a specific image; it was never information you could reuse. State the constraint you actually have — the size budget — and make the machine search for the best quality that satisfies it. It's a small shift in framing, but it eliminates the entire guess-and-check loop, and it runs fast enough in the browser that there's no reason to ship your pixels to a server to do it.

If you want to try the workflow without writing the encode loop yourself, the target-first image compressor is linked above — set a budget, drop an image, read the actual size off the result card.

Disclosure: I built this tool at ToolkitLoop — it's a free, browser-side compressor with no sign-up, and your images never leave your machine.