Why an exact file size matters
Most image compressors ask you to pick a quality percentage and then hope the result is small enough. That is the wrong way round. In practice you rarely care about quality settings — you care that an upload form accepts the file. University applications, visa portals, job boards, government e-service sites and older content management systems all enforce hard ceilings, and they reject anything one byte over.
This tool works backwards from that constraint. You give it the ceiling, and it finds the highest quality that stays underneath. That is a different operation from “compress at 70%”, and it is the one that actually gets your form submitted.
How the compression works
When you press Compress, the image is decoded and re-encoded through your browser's Canvas API. The tool runs a binary search across the quality range: it encodes at a mid-point quality, measures the resulting byte size, and then moves the search window up or down depending on whether the result fits. After nine passes it has converged on the highest quality that stays under your target, usually within a few hundred bytes of the ceiling.
Quality reduction alone is not always enough. A 48-megapixel phone photo squeezed to 50 KB would look like mud even at the lowest quality setting, and sometimes it simply cannot get there at full resolution. When that happens the tool scales the pixel dimensions down by 15% and repeats the quality search, looping until the target is met. The minimum width field is your guardrail: the image will never be scaled below it, so you stay in control of how much resolution you are willing to trade.
If the target still cannot be reached at your minimum width, the tool tells you instead of silently returning an oversized file. Lower the minimum width or raise the target and run it again.
Common size limits and what they are for
| Target | Typically required by | Realistic result |
|---|---|---|
| 50 KB | Older government portals, ID photo uploads | Expect visible softening; keep dimensions small |
| 100 KB | Exam applications, visa forms, job portals | Good for photos up to roughly 1000 px wide |
| 200 KB | Forum avatars, CMS thumbnails, email attachments | Comfortable quality at 1200–1600 px |
| 500 KB | Blog images, product listings, marketplace photos | Near-original quality at full width |
| 1–2 MB | Print submissions, high-resolution portfolios | Barely distinguishable from the source |
Choosing between JPEG and WebP
JPEG is the safe default. Every upload system built in the last thirty years accepts it, and if you are compressing for a form on someone else's website, that compatibility is worth more than a few kilobytes.
WebP reaches the same perceived quality at roughly 25–35% smaller file sizes, which means less scaling and a sharper result for the same ceiling. Use it when you control the destination — your own site, an app you are building, or storage you manage. Avoid it for third-party forms that have not been updated in years.
PNG is not offered as an output. PNG is lossless, so it has no quality dial to turn — the only way to shrink it is to reduce dimensions or colour depth. For photographs it produces files several times larger than JPEG at the same visual quality. If your source is a PNG, converting it to JPEG or WebP here is exactly what you want.
Getting better results at small targets
- Crop before compressing. Every pixel you remove is quality you do not have to spend. Cropping to the subject beats compressing the whole frame.
- Lower the minimum width for tiny targets. Below about 100 KB, holding a large width forces the quality down far enough to create visible blocking. A smaller, sharper image usually looks better than a large, mushy one.
- Start from the original, not a compressed copy. Re-compressing a file that has already been through JPEG stacks artefacts on top of artefacts. Go back to the camera file where you can.
- Screenshots and text need different handling. Sharp edges and flat colour are the worst case for JPEG. Reduce the dimensions rather than the quality, or use WebP, which handles hard edges more gracefully.
Your files stay on your device
There is no upload step here. The compression happens in your browser using standard web APIs, which means your images are never transmitted, never written to a server, and never retained. It also means there is no queue, no daily limit and no file size cap — the only real constraint is your device's memory.
A useful side effect: re-encoding through a canvas discards EXIF metadata. GPS coordinates, camera serial numbers and timestamps are stripped from the output, which is usually what you want before posting a photo publicly.