Why “compress to an exact size” is a different problem than “compress to a quality level”
Ordinary compression tools ask you to pick a quality percentage and show you what size comes out. That’s backwards from what most people actually need when a form says “photo must be under 20KB.” You don’t care about the quality number at all — you care about the byte limit, and you want the best possible quality that still respects it. Getting there by hand means repeatedly nudging a slider, re-exporting, checking the file size, and trying again, which is exactly the tedious loop this tool automates.
How the automatic search works
Under the hood, the tool uses a binary search over the JPEG quality parameter. It starts by encoding at a mid-range quality (around 50%) and checks the resulting byte size. If that’s still too big, it tries a lower quality; if it comfortably fits under the target, it tries a higher one — each step cutting the remaining search range in half. Within roughly six to eight encode passes, it converges on the highest quality setting that still produces a file at or under your target size. This is dramatically faster and more precise than manual trial and error, and it consistently finds a better result than guessing, because it’s exploring the full quality range systematically rather than stopping at the first setting that happens to work.
Why these specific size limits exist
If you’ve ever wondered why a government portal insists on a photo “not exceeding 20KB” when your phone camera produces 4MB images by default, the answer is almost always legacy infrastructure. Many public-sector application systems — income certificate portals, competitive exam registration (banking, civil services, teaching), passport and visa applications, university admission forms, and digital KYC for banks — were built on infrastructure sized for a much earlier era of storage and bandwidth costs, and the upload limits were set then and never revisited. The technical justification for a hard 20KB or 50KB cap has mostly disappeared, but the requirement hasn’t, so the practical task remains: get a recognizable, compliant photo under an oddly small ceiling.
Job portals impose similar limits on resumes-as-images or profile photos, usually to keep their own storage and page-load costs predictable across millions of user uploads, even though a few hundred extra kilobytes per user would be imperceptible to any modern host.
Getting a usable result at very small targets
At generous targets like 100KB or 200KB, you can usually keep an image looking essentially unchanged. At aggressive targets like 10KB or 20KB, especially for a photo with real detail (a face, not a simple graphic), there’s only so much a quality search can do — the byte budget is simply too small for high detail at typical photo resolutions. The single most effective lever in that situation isn’t quality, it’s pixel dimensions: a 3000×4000px photo squeezed to 20KB will look far worse than the same photo resized to 400×533px first and then compressed to 20KB, because smaller dimensions mean far less detail needs to be encoded per byte. Most photo/signature upload requirements have an implicit expectation of passport-photo-scale dimensions (roughly 200-400px on the long side) — if the form doesn’t specify pixel dimensions, resizing down before running the size search will get you a noticeably cleaner result than compressing a full-resolution photo alone.
A practical workflow
For strict portals, do it in two passes: first use the Resize tool to bring dimensions down to something reasonable for the intended use (a photo ID doesn’t need 12 megapixels), then run the result through this tool with your required byte target. You’ll get a sharper, more legible image at the same file size ceiling than compressing the original resolution directly.