How target-size image compression works

A normal image compressor asks you to choose a quality percentage. That control is useful when you care about appearance but do not have a strict upload limit. It is frustrating when a form says the file must be under 50KB or 100KB, because a quality value does not map to one predictable file size.

Target-size compression reverses the workflow. You provide the maximum number of bytes, the compressor tries multiple encodings, and it keeps the highest-quality result that actually fits.

File size and pixel dimensions are different

File size is the number of bytes stored on disk. Pixel dimensions describe the width and height of the image. A 2000 by 1500 pixel image can be smaller than a 1000 by 750 pixel image if the first contains simple color areas and the second contains heavy detail, noise, or fine texture.

That is why a trustworthy tool measures every generated file. It cannot calculate the final size from dimensions alone.

The browser first decodes the source

The selected file is read as a local browser object. Modern browsers can turn a file or Blob into an ImageBitmap, which can then be drawn to a canvas. The browser also applies stored orientation information so a portrait photo does not appear sideways.

MDN documents that createImageBitmap accepts Blob sources and can follow EXIF orientation. ImageCompressor.pics uses that browser path when it is available and falls back to a normal image element where needed.

Lossy formats allow a quality search

JPEG and WebP encoders accept a quality value. A lower value usually produces fewer bytes, but the relationship is not linear. Moving from 90 percent to 80 percent may save very little on one photo and a large amount on another.

The compressor therefore uses a binary search:

1. Encode once near the middle of the allowed quality range.
2. Measure the Blob size returned by the browser.
3. If the result is below the target, try a higher quality.
4. If it is above the target, try a lower quality.
5. Repeat while remembering the best result that stayed under the limit.

Each pass cuts the remaining quality range roughly in half. A small number of encodes can find a strong result without testing every possible percentage.

The browser API behind the export is HTMLCanvasElement.toBlob. It returns the real Blob that will be downloaded, so its byte length is the evidence used for the final status.

Dimensions change only when quality is not enough

A large, detailed camera photo may remain over 20KB even at a very low JPEG quality. Continuing to reduce quality creates blocky edges, color smearing, and unreadable details. At that point, reducing pixel dimensions is usually the better tradeoff.

ImageCompressor.pics estimates a smaller width and height from the gap between the current output and the target. It redraws the image at those dimensions, then repeats the quality search. It never enlarges the original because upscaling cannot create real detail and would add unnecessary bytes.

PNG behaves differently

PNG is lossless. The browser does not offer the same useful quality control that JPEG and WebP provide. When a PNG is over a tiny target, the main available lever is pixel dimensions. This is why a detailed transparent PNG can be difficult to fit under 20KB or 50KB without becoming visibly small.

If the destination accepts WebP, it can preserve transparency while offering lossy compression. If it accepts JPEG and transparency is not required, JPEG is usually the more compatible small-file option.

Why exact byte equality is the wrong promise

Most forms publish a maximum, such as "100KB or less." The correct goal is to stay at or below that number. Trying to pad a 72KB file to exactly 100KB adds no visual quality. It only creates waste.

Some files also cannot land on every possible byte value because encoders produce discrete outputs. A result can be safely under the limit without being numerically identical to it.

What re-encoding does to metadata

Canvas export writes a new image from decoded pixels. It does not copy the original EXIF block, so stored camera information and GPS coordinates are removed from the result. This is useful for private photos, but it also means copyright, capture date, and color-profile metadata may be removed.

How to get a better result

• Crop empty borders and irrelevant background before targeting a very small file.
• Enter any required width or height from the destination form.
• Use JPEG for photographs when broad compatibility matters.
• Use WebP when the destination supports it and quality per byte matters most.
• Use PNG for transparency and sharp graphics when the size budget allows it.
• Open the downloaded file and inspect faces, text, signatures, and fine edges before submitting it.

The goal is not the smallest file at any cost. It is the clearest useful image that fits the real limit.