100KB sits in an unusually useful spot for image file sizes — small enough to keep a web page fast, large enough that a normal photo still looks genuinely good. It’s the size you’ll bump into less as a hard form requirement and more as a practical target you set for yourself: getting a blog post’s images under control, staying under a CMS upload cap, or just making sure a page doesn’t take forever to load on a phone.
Why file size matters more than people think
It’s easy to treat image compression as a cosmetic concern — something you’d only bother with if storage space were tight. In practice, image weight is one of the biggest, most controllable factors in how fast a web page loads. Google’s Core Web Vitals — specifically Largest Contentful Paint, which often is the largest image on the page — directly measure how long visible content takes to render, and oversized images are consistently the single biggest culprit when a page scores poorly. A handful of 2-3MB photos straight off a phone, dropped into a page without any compression, can easily multiply that page’s load time several times over compared to the same images compressed to a reasonable size.
100KB per image is a sensible line to aim for if you want a page that feels fast without obsessing over every kilobyte. It’s roughly the point where, for a typical photo at typical display sizes, further size reduction starts trading away visible quality faster than it saves meaningful load time.
How the compression actually gets there
Rather than asking you to pick a quality percentage and check afterward whether the result happens to be small enough, this tool works backwards from the size you actually want. It encodes the image at a range of quality settings, checks the resulting file size each time, and homes in — through roughly eight attempts — on the highest quality setting that still lands at or under 100KB. That matters because the “right” quality setting to hit a specific size target varies hugely from image to image: a simple, low-detail photo might comfortably hit 100KB at quality 85, while a busy, highly detailed one might need quality 50 to get there. Picking one fixed quality percentage for every image, the way a basic slider does, either wastes headroom on simple images or produces inconsistent, sometimes-too-large results on complex ones.
If quality reduction alone genuinely can’t reach 100KB — which happens with very large, very detailed source photos — the tool falls back to also reducing the image’s pixel dimensions, the same way it does at smaller, more aggressive targets. At 100KB this is much less common than it is at, say, 20KB, since there’s considerably more size budget to work with.
Where format choice changes the outcome
This tool defaults to JPG output because JPG’s lossy compression is what makes hitting a specific size target on a real photograph practical and predictable. If your source image is a PNG — a screenshot, a logo, a graphic with flat color areas and sharp edges — converting it to JPG to hit a 100KB target can introduce visible artefacts around text and hard edges that weren’t there in the lossless original, even though the same artefacts would be far less noticeable on an actual photograph. For that kind of content, a PNG-specific compressor (which works by reducing dimensions rather than introducing lossy artefacts) usually gives a cleaner result.
A note on resizing first if you control the source
If you’re preparing images you’ve taken or designed yourself, rather than working with whatever a user uploaded, it’s often worth resizing to your actual intended display dimensions before compressing for size. A 4000px-wide photo that will only ever be shown at 800px wide is carrying around three times the linear resolution it needs, which means the compressor has to work harder — and trade away more visible quality — to hit the same KB target than it would on an image that was already sized appropriately. Getting the dimensions right first, then compressing, generally beats compressing an oversized image directly.