"Compress this image to under 100 KB" is one of the most common support tickets image tools receive. It sounds trivial — press the button, get a smaller image — but the way most tools handle it is either misleading or subtly broken. This piece explains why, and gives you the practical playbook that actually hits the target.
The problem with one-click preset compression
Nearly every online image compressor with a "Compress to X KB" button works the same way: it picks a fixed quality setting and dimension cap that usually produces something close to the target, then hopes for the best. On a typical smartphone photo (~4 MB, 4000 px wide) those defaults typically land within 20–40% of the requested size.
That's fine when the target is a rough guideline. It fails when the target is a hard rule. Job-portal photo uploads that hard-reject anything over 50 KB. Sarkari and SSC application forms that cap at exactly 40 KB. Corporate email systems that bounce attachments over 2 MB without warning. In all those cases "close to 100 KB" is not the same thing as "under 100 KB".
Why hitting an exact target is a search problem
Image compression is non-linear. Quality 80 versus quality 82 might produce a 5% file-size difference on one image and a 25% difference on another. The relationship depends on the source image's complexity, the input format, the output format, and the resolution. There is no closed-form formula that says "for this image, quality 74.3 will produce exactly 100 KB".
The correct approach is iterative. Compress at a starting quality (say 85), measure the actual byte count of the output, and if it's over target reduce quality and try again. If it's under target you can try slightly higher quality to improve fidelity. This is a binary search over the quality slider — the same algorithm computer science undergraduates learn for finding numbers in sorted arrays, applied to image encoding.
Binary search converges in log₂(N) steps. Over the 20–100 quality range, that's 7 iterations to pin the highest quality that stays under the target — which takes about 400 ms in a modern browser. Fast enough to run entirely client-side, without any perceptible delay.
When quality alone can't hit the target
Sometimes the target is small enough that no amount of quality reduction will get you there while preserving the source dimensions. A 4000×3000 pixel photo compressed to quality 20 might still be over 50 KB just because of the pixel count.
The fix is to drop dimensions after the quality search bottoms out. Downscale by 20% on the longest edge and try the whole quality search again. Repeat until you land under target or hit a floor (usually 200 px minimum, below which the image stops being useful).
That's exactly what our iterative KB compressor does — binary-search quality first at the source dimensions, drop dimensions by 20% if we bottom out, repeat until we land under target or report honestly that we can't hit the target without unusable quality loss.
Worked examples: what the maths looks like in practice
Example 1: A 3.2 MB photo compressed to under 100 KB
Take a typical smartphone photo (3.2 MB JPEG, 4000×3000 pixels). Ask the iterative compressor to hit under 100 KB in JPEG:
- Attempt 1: quality 85 → 890 KB. Over target. Lower quality.
- Attempt 2: quality 52 → 280 KB. Over target. Lower quality.
- Attempt 3: quality 36 → 165 KB. Over target. Lower quality.
- Attempt 4: quality 28 → 110 KB. Over target. Lower quality.
- Attempt 5: quality 24 → 93 KB. Under target. Try higher.
- Attempt 6: quality 26 → 98 KB. Under target. Try higher.
- Attempt 7: quality 27 → 102 KB. Over. Stop — quality 26 wins.
Final: 98 KB at quality 26, source dimensions unchanged. The compressor takes ~600 ms. Visually acceptable for a thumbnail; pixelated as a full-page hero.
Example 2: Same photo compressed to under 20 KB
Now the same photo, target under 20 KB. Quality alone bottoms out at quality 20 producing 68 KB — still 3× over target. Time to drop dimensions:
- Downscale to 3200×2400 (80% of original). Binary-search quality → best 42 KB at quality 25. Still over.
- Downscale to 2560×1920 (64% of original). Best 26 KB at quality 24. Still over.
- Downscale to 2048×1536 (51% of original). Best 18 KB at quality 25. Under target.
Final: 18 KB at 2048×1536 pixels, quality 25. Not usable as a print or hero, but perfectly fine for an ID-form thumbnail or a text-adjacent icon.
Format choice matters more than most people realise
Everything above assumed JPEG output. Swapping to WebP typically saves 25–35% for the same visible quality, which is often enough to hit the target without any dimension reduction at all. In Example 1 above, re-running with WebP output lands at 68 KB at quality 82 — three quality bands higher, visually indistinguishable from the source, well under target.
Rule of thumb: if the destination supports WebP (every modern browser, most CMS templates, most social platforms), pick WebP. If the destination is a legacy corporate email system or a government portal with a JPEG-only rule, you're stuck with JPEG and the iteration game.
The practical playbook
For any "hit an exact KB target" problem:
- Check whether the target is a rule or a guideline. If it's a rule (form upload, corporate cap), use the iterative tool. If it's a guideline, the preset pages get you close enough.
- Pick WebP output if the destination supports it. WebP's efficiency advantage often turns an aggressive target into an easy one.
- Consider cropping first. Most tight KB targets are for small displays (thumbnails, avatars, form photos). If you crop out unneeded background, you shift the file-size problem before it becomes a compression problem.
- Use iterative compression when the target is aggressive. Under 100 KB for a real photo needs binary search; the preset approach is a coin flip.
- Accept honest failure when it's the answer. Sometimes a photo genuinely can't hit the target without becoming unusable. Better to know that in the tool than to submit a form with an unreadable photo.
Try it
Our iterative KB compressor implements exactly this algorithm — binary-search over quality, downscale as a fallback, honest failure when the target is impossible. Runs entirely in your browser, converges in about 500 ms for typical inputs. Free, no signup.