Compress an image to 100KB, 50KB or any size you need

How to compress an image to 100 KB, 50 KB or 20 KB

An upload form that says “maximum 100 KB” is checking one number: the byte count of the file. It does not look at the picture. You have three things to work with — the format, the quality the encoder is allowed, and the number of pixels — and the best result under a hard limit usually uses more than one of them.

What lossy compression throws away

JPEG converts the image from RGB into one brightness channel and two colour channels, and usually stores the colour at half the width and half the height (4:2:0), because the eye resolves colour detail far less sharply than brightness. It cuts each channel into 8×8 blocks and runs a discrete cosine transform, which turns 64 pixels into 64 frequency coefficients. Quantisation then divides each coefficient by a value from a table and rounds it. That rounding is where information is lost, and the quality number does nothing more than scale the table. Fine detail lives in the high frequencies, which round to zero first, and long runs of zeros cost almost nothing once entropy coding packs them. Pushed too far, you see the 8×8 grid as blocks and ringing around sharp edges and text. MozJPEG, used here, writes standard JPEG files that open everywhere, but chooses its rounding per coefficient by weighing size against error (trellis quantisation), and uses progressive scans and optimised Huffman tables.

WebP (lossy) is a VP8 video keyframe. Each block is predicted from its already-decoded neighbours and only the difference is transformed and quantised, then packed by an arithmetic coder. An in-loop filter smooths block edges, so an over-compressed WebP looks soft rather than blocky. Colour is always 4:2:0; this tool converts to it edge-aware, which limits colour bleeding on red edges and text.

AVIF is an AV1 keyframe. It picks block sizes from 4×4 up to 128×128, chooses among many directional predictors and several transforms, and runs filters after decoding that suppress ringing. Its failures are lost texture and smoothing rather than blocks, and it can keep full colour resolution. The price is encoding time: in WebAssembly a large photo takes seconds, not milliseconds.

Because the three codecs throw away different things, quality numbers do not translate between them. Quality 75 in AVIF discards more than 75 in JPEG and typically still looks at least as good.

“Without losing quality”: what is actually true

Every lossy encode discards information, and re-encoding a JPEG as JPEG discards some again. What you can honestly get is a file that is visually indistinguishable at the size it will be viewed. Check that yourself: open the comparison at 100% and look at edges, skies, skin and small text, which show damage first. If you need every pixel preserved, the only answer is lossless — the PNG path below.

Why hitting an exact size needs a search

There is no formula from “100 KB” to a quality setting. The same quality gives a tiny file for a clear sky and a large one for foliage, because size depends on how much detail the encoder has to describe. So the only reliable method is to encode, count the bytes and adjust.

File size rises with quality almost monotonically, which makes a binary search work. This tool encodes at quality 92 first; above that, size climbs steeply for no visible gain. If that fits, it is the answer. Otherwise it encodes at quality 10; if even that is over the limit, no quality will fit and you are told so, with the smallest size reached. If 10 fits, the answer lies between, and each further encode halves the interval. The range 10–92 holds 82 steps and log₂82 ≈ 6.4, so seven more encodes pin the highest fitting quality: nine at most. AVIF is capped at six, which still narrows it to within six quality steps. The search stops early once a file is within 2% of the limit, and because “almost monotonic” is not “monotonic”, it keeps the best fitting file it has measured rather than trusting the last one.

Limits are counted with 1 KB = 1,000 bytes, so a 100 KB target means at most 100,000 bytes. A site that means 102,400 bytes accepts that file too.

Resize before you crush the quality

The useful measure is bits per pixel. A 100 KB file is 800,000 bits. Spread over a 12-megapixel photo (4000×3000 = 12,000,000 pixels) that is 0.067 bits per pixel. At 1600×1200 (1,920,000 pixels) it is 0.42 bits per pixel: 6.25 times as much information for every pixel that remains. A 20 KB limit is 160,000 bits; over 1600×1200 that is 0.083 bits per pixel, over 800×600 it is 0.33.

Pixel count goes with the square of the width, so halving the width quarters the pixels and quadruples the bits each one gets. At very low bits per pixel an encoder has to zero nearly every coefficient, and the result is blocks and smears. The same bytes spent on fewer pixels at a moderate quality look far better — and a form that wants 50 KB rarely displays the image larger than a few hundred pixels anyway. When a target is out of reach, this tool works the same sum backwards: size follows pixel count, so it suggests the edge length that scales the smallest file it measured under the limit, with a margin.

How to compress a PNG without losing quality

PNG is lossless. Before compressing, it runs a filter on each row — None, Sub, Up, Average or Paeth — that predicts each byte from its neighbours, then compresses the leftovers with DEFLATE (LZ77 matching plus Huffman coding). Files with the same pixels can differ a lot in size depending on which filters and settings were chosen, and whether the colour type is larger than needed: an image with few colours can be a palette, a grey one needs no colour channels, an opaque one no alpha.

OxiPNG tries those options and keeps the smallest, so the output decodes to the same pixels. Two details to know: the image is decoded to 8 bits per channel first, so a rare 16-bit PNG comes out 8-bit; and the hidden colour of fully transparent pixels is rewritten, which you cannot see but compresses better. Screenshots, logos and interface graphics gain the most. A photograph saved as PNG stays large, and no lossless tool can bring it to a KB target: use JPEG or WebP for that.

Which format to choose

If a form lists the formats it accepts, that list decides. Otherwise, for a hard limit, the more efficient format spends the same bytes on more detail.

Metadata is not carried over

Compressing here decodes the image to pixels and writes a new file, so the EXIF block — camera model, capture time, GPS position — is not copied into the output. Rotation is applied to the pixels first, so a phone photo stays upright. If you want to remove that metadata while keeping every pixel exactly as it is, without re-encoding, use Remove EXIF data instead.