The quality slider is not a size slider
Every image editor gives you a JPEG quality value from 1 to 100, and almost everyone assumes it maps to file size in some predictable way. It does not. Quality 80 does not mean 80% of the original bytes. It sets how aggressively the encoder discards detail, and the number of bytes that comes out the other side depends entirely on what is in the picture.
A passport photo of a face against a plain white studio background compresses beautifully, because most of the frame is a single flat colour and JPEG stores flat areas almost for free. The same quality setting on a photo taken against a patterned curtain, or with visible sensor noise from a dim room, can produce a file three or four times larger. Noise is the expensive part. It looks like fine detail to the encoder, so the encoder faithfully spends bytes preserving something you never wanted.
This is why quality 60 gives you 47 KB on one photo and 180 KB on the next, and why manually nudging the slider is a frustrating way to hit a hard limit.
What an exact-KB compressor actually does
The honest answer is that it guesses, checks, and guesses again. There is no formula that converts a target size into a quality value, because the relationship depends on the image. So the tool runs a search.
It encodes the image at some quality, measures the actual bytes, and uses that result to pick the next attempt. Too big, go lower. Too small, go higher and recover some quality you did not need to give up. Each round halves the remaining range, so a target is usually reached in six to eight attempts, which is fast enough to feel instant in a browser.
The detail that separates a good implementation from a careless one is what it does on the last step. A careless tool stops at the first result under the limit. If your ceiling is 50 KB and it lands on 31 KB, it hands you 31 KB and calls it done. You just threw away a third of your available quality budget for nothing. A good tool keeps searching for the largest file that still fits, because every byte under the ceiling that you do not use is quality you gave away for free.
Our custom-size compressor works this way, and so do the fixed-target pages.
When quality is the wrong lever
There is a floor below which reducing quality stops helping and starts destroying. Push a 12-megapixel phone photo down to 20 KB by quality alone and you get the blocky, smeared look everyone recognises, because JPEG works on 8x8 pixel blocks and at extreme compression those block edges become visible. The face goes muddy. Text in a scanned document becomes unreadable.
The fix is resolution, not quality. A form that wants a 20 KB photo does not need 12 megapixels. It is going to be displayed at perhaps 200 by 230 pixels on an application preview, and printed at postage-stamp size if at all. Resizing to roughly the dimensions the form actually asks for, and then compressing at a sane quality, produces a dramatically better-looking result than keeping full resolution and crushing quality to reach the same byte count.
The general rule: cut dimensions first until you are near what the form specifies, then use quality to fine-tune the last stretch. Doing it the other way around is what produces the pixelated photos you see rejected.
Things that quietly inflate your file
Metadata. A photo straight off a phone carries EXIF data: camera model, exposure settings, often GPS coordinates, and sometimes an embedded thumbnail that is itself a small JPEG. On a 20 KB target that overhead is a meaningful fraction of your budget, and the location data is something you probably do not want attached to a government application anyway.
The wrong format. Saving a photograph as PNG is the single most common cause of a file that will not come down. PNG is lossless, so it has no quality dial at all, and for photographic content it is routinely five to ten times larger than an equivalent JPEG. If your photo is stuck at 2 MB no matter what you do, check the extension first.
Scanning at print resolution. A signature scanned at 600 dpi produces an enormous file full of paper texture. 150 dpi is more than enough for a signature that will be shown at a few hundred pixels wide, and the reduced paper noise compresses far better.
A workflow that works
- Check the form's actual requirement first, including the minimum. Many portals reject files that are too small as well as too large, and a file that is suspiciously tiny is often a sign you over-compressed.
- Start from the highest-quality original you have, not from a copy that has already been through a messaging app. Every re-save of a JPEG loses a little more, and those losses accumulate.
- Crop and resize toward the dimensions the form specifies.
- Compress to the target with a tool that searches for the largest file under the limit rather than the first one that fits.
- Open the result at full size before uploading. If the face looks soft or blocky, your dimensions are still too large for the byte budget.
Why doing this in the browser matters
The files involved are identity documents. A photograph of your face, your signature, sometimes a scan of a certificate. Uploading those to a server to be resized means trusting a retention policy you cannot inspect.
Compression is pure arithmetic on pixels. There is no reason it needs a server, and every tool on this site does it inside your browser tab instead. The file never leaves your device, which you can confirm by disconnecting from the network after the page loads and watching it keep working.