How this hits the number
JPEG and WebP encoders do not take a file size. They take a quality setting between 0 and 1, and what comes out the other end is whatever size it happens to be. There is no quality value that means “95 KB”. So the tool works backwards:
- Encode once at high quality. If that already fits your budget, keep it — you paid nothing for the limit.
- Otherwise encode at the lowest usable quality. If that still overshoots, no quality setting can save it, so skip to step 4.
- Binary-search the range in between, about ten passes, keeping the best result that still fits. Ten passes narrows a range of 0.9 down to under 0.001, which is finer than the encoder itself resolves.
- Only if quality alone cannot get there, scale the image down 15% and run the search again. Repeat up to six times.
Quality comes down before pixels do, because at normal viewing sizes a quality drop is much less noticeable than a resolution drop. The order matters more than either lever.
A worked example
A 4.2 MB photo from a phone, with a 200 KB limit on a job application form:
- Quality 0.95 → 1.9 MB. Way over.
- Quality 0.05 → 88 KB. Under, so a fit exists somewhere in between.
- Ten passes later, quality 0.62 → 197 KB. That is the answer: 98.5% of the budget used, full resolution kept, no scaling needed.
The same photo against a 20 KB limit runs out of quality, drops to 85% dimensions, and finds its answer there instead.
Why KB here means 1,000 bytes
“KB” is genuinely ambiguous: Windows shows 1 KB as 1,024 bytes, macOS shows it as 1,000. This tool uses 1,000, and the reason is which way the mistake hurts. If the form that gave you the limit meant 1,024 and we aimed at 1,000, your file is safely under. If it meant 1,000 and we aimed at 1,024, your file is 2.4% over and gets rejected at the door. One reading fails quietly and safely; the other fails at exactly the moment you needed it to work.
What this does not do
- It does not make a small image look better. Compression only ever removes information. If your source is already blurry, the output is a smaller blurry image.
- It does not keep animation. An animated GIF becomes a single still frame. There is no way to get the animation back afterwards.
- It does not keep transparency in JPEG. JPEG has no alpha channel, so transparent areas are filled with white. Choose PNG or WebP if you need transparency.
- It does not preserve EXIF. Camera metadata, including GPS location, is dropped in the re-encode. For most uploads that is a privacy improvement, but if you need that data, keep your original.
- It can run out of memory on a phone with an enormous image. There is no size limit in the tool, but a device has finite memory. If a browser refuses to decode an image, the tool says so rather than hanging.
How big a file can you put in?
There is no limit, because there is no upload. Every other compressor has a cap — a free tier that stops at 5 MB, a queue that takes five files at a time, a paid plan to go beyond. Those limits exist because someone is paying for bandwidth and storage on the other end. Here the work happens on your own device, so there is nothing to meter.
Tested on a desktop browser up to 192 megapixels — a 16,000 × 12,000 image, compressed in about seven seconds. Nothing broke at any size on the way up, so the practical ceiling is your device's memory rather than a number anyone chose. A phone will manage less than a laptop; a ten-year-old phone less again.
The same applies to the target: the preset buttons are shortcuts, not limits. Type any
value into the field — 750 KB, 40 MB, 1 GB — and
it will aim for exactly that.
Batches are unlimited too. Drop fifty images and they process one after another, with a zip at the end.
Common questions
Are my photos uploaded anywhere?
No. Compression runs in this tab through the canvas API and a web worker. There is no network request in the page's code, and you can confirm that yourself: open your browser's network tab, compress something, and watch nothing happen.
Why can't it land exactly on 100 KB?
Because no quality setting maps to an exact byte count. 97 KB against a 100 KB limit is the correct answer — the goal is the largest file that still fits, and going over by even a few bytes makes the file useless for the thing you needed it for.
Why did my image lose resolution?
Only because quality alone could not reach your budget. That usually means the limit is very tight for the size of image, and something had to give. If the resolution loss matters more than the exact limit, try WebP instead of JPEG first — it often buys back enough bytes to keep full dimensions.
Should I use JPEG or WebP?
WebP fits roughly 25–35% more image into the same bytes, so at a fixed budget it simply looks better. Use JPEG when the receiving system is old or strict. Government portals, older applicant-tracking systems and some print services still reject WebP outright — if the form says JPG, send JPG.
Does compressing twice make it smaller?
Smaller, yes; worse, definitely. Every lossy re-encode throws away information the previous one kept, and the damage accumulates in a way that cannot be undone. Always start from your original file rather than from a file this tool already produced.
References
- MDN —
HTMLCanvasElement.toBlob(), the encoder this tool drives, and its quality parameter. - MDN —
OffscreenCanvas, which is what lets the search run without freezing the page. - MDN — image file type guide, for what each format can and cannot carry.