How to Compress an Image to a Target File Size

The request looks simple — make this photo 100KB — but no encoder can honour it directly. A JPEG or WebP encoder takes a quality target, compresses, and produces whatever size that image happens to need. Two photographs at identical dimensions and identical quality can differ threefold in bytes, because a flat studio background compresses to almost nothing while foliage or a crowd does not. That is why tools promising an exact size internally compress several times and keep the closest result, and why doing the same thing deliberately gets you there faster.

There are only two levers that matter, and they are not equally strong. Pixel count is the first and by far the larger: file size scales roughly with the number of pixels, so halving both width and height removes about three quarters of the data before quality is touched at all. Quality is the second, and it has a floor below which the image visibly falls apart. Most people drag quality down to 20 while leaving a 4000-pixel-wide photo untouched, get a muddy 300KB file, and conclude the limit is impossible. Resizing first and leaving quality near 75 almost always beats it.

Format is a third factor people forget. The same picture at the same visual quality is meaningfully smaller as WebP than as JPEG, and smaller again as AVIF. If the form accepts WebP, switching format can clear the limit on its own with no quality loss at all. If it only accepts JPG — which most official portals do — that lever is unavailable and the first two have to carry it.

Lossy image compression works by discarding detail the eye is least likely to miss, and how much detail exists is a property of the picture. A quality setting is an instruction about how aggressively to discard, not a promise about the result. Feed the encoder a photograph of a white wall and quality 80 might produce 40KB; feed it a market stall at the same size and quality and it might produce 400KB. Nothing is wrong in either case.

This is why the honest workflow is measurement, not prediction. Compress once at a sensible starting point, read the exact output size, and you now know something specific about this image rather than something general about the setting. A second pass informed by that number lands close, and a third is rarely needed. Tools that advertise an exact target size are running this loop for you, several times, and returning the nearest hit.

Start with dimensions. A photograph straight off a modern phone is somewhere between 3000 and 4500 pixels on its long edge — far more than any web page, upload form or printed ID photo needs. Reducing the long edge to 1600 pixels cuts the pixel count of a 4000-pixel image by roughly 84%, and file size falls in rough proportion. Nothing about the visible quality of the image at normal viewing size changes, because the extra pixels were never being displayed.

Then adjust quality, and adjust it gently. The perceptual cost of quality is not linear: dropping from 95 to 80 is nearly invisible and saves a great deal, dropping from 80 to 65 is noticeable on faces and smooth gradients, and below 60 you get visible blocking around hard edges and banding in skies. If a target needs quality below 60, the image is still too large in pixels — go back to the first lever.

Only when both are exhausted should you consider cropping. Removing content is a real change to the image rather than a compression decision, so it belongs last, but it is legitimate when a photo has wide empty margins that carry no information.

These are starting points for a typical phone photograph, not guarantees — a busy image will land above the estimate and a simple one below it. Use them for the first pass, read the real output, then adjust. All of them assume JPEG output, because that is what portals with size limits almost always require.

Two ambiguities cause most rejected uploads, and neither is about compression. The first is what KB means. A strict reading is 1,024 bytes, but plenty of forms are written against 1,000, and some validate on the number their own operating system reports. A file at 102,000 bytes reads as 99.6KB one way and 102KB the other, and only one of those passes a 100KB check. Aim a little under the stated limit rather than at it.

The second is whether the limit applies per file or per submission. A form allowing 200KB per image and 1MB in total will accept five images individually and reject the set. Add up the compressed sizes before submitting, and if the total is the binding constraint, spend the budget where it matters — the portrait can afford more bytes than the signature scan.

Some portals also enforce a minimum dimension alongside a maximum file size, which is the one combination that makes the first lever unavailable. Where a form demands, say, at least 600x600 pixels and under 50KB, you cannot resize below 600 and must reach the target on quality and format alone.

Everything above assumes a photograph. Documents and screenshots behave differently, because their content is large flat areas and hard black edges — exactly what JPEG handles worst. A scanned form at JPEG quality 70 develops grey haloes around every letter, and the file is often larger than a lossless version would have been.

For text-bearing images, keep quality high — 90 or above — and take the saving from dimensions instead, since text stays legible at surprisingly low resolution. Where the format is your choice, PNG is frequently both smaller and cleaner for screenshots of interfaces, and WebP handles the mixed case of a screenshot containing a photograph better than either.