Compress an image toward a KB target — free and private

Indian online forms do not ask for "good quality". They ask for 20 KB to 50 KB, and they reject anything outside the band. That is a search problem — find the best quality whose encoded output lands inside the window — and it is exactly what a binary search solves in about eight iterations.

Most "image compressor" sites upload your photo to a server, which is a real problem when the photo is a selfie next to your signature and an ID number. Nothing leaves this tab.

Batch mode matters for documents: a 40-page application can need a dozen images resized to different targets, and doing it in one pass saves a tedious afternoon.

Byte limits are enforced by the form before any human sees the file, and the error message rarely says which requirement failed. Hitting the number in advance is what turns a rejected upload into a completed application.

The compressor tests encoder settings against the requested byte window. Output size is not perfectly predictable, and some windows cannot be reached; read the result card and inspect the image.

Photographs of identity documents, signatures and marksheets are exactly the files that should not be handed to a stranger's server, and they are also the files that most often need compressing. Processing them in the tab removes that trade-off entirely.

This tool exists for images handled in a hurry: no queue, no account, no upload, and a result you can verify on the spot. The explanation below is the same one we would give a colleague who asked how it works.

On a phone, memory is the real constraint rather than any size limit. A 12-megapixel photograph is about 36 MB once decoded into pixels, so compiling a batch of twenty and holding every result in memory at once will get a mobile browser killed well before it runs out of storage. Process batches of ten to fifteen on a phone; on a laptop the same job is unremarkable.

Pixels, DPI metadata and physical print size are distinct. For example, 35 mm at 300 pixels per inch is approximately 413 pixels, but pixels alone cannot guarantee a printer produces a 35 mm image. If the instructions also require DPI metadata or a measured print, check those separately.

Accepted inputs are JPEG, PNG, WebP, AVIF, HEIC, GIF and BMP images up to 50 MB each. SVG, HTML and other script-bearing formats are refused outright rather than sanitised, because a file that can execute code has no business being re-encoded — and an upload field that accepts one is a security hole rather than a feature. Several files can be queued where the workbench supports it. Batch, page and memory limits apply; check every output.

The image engine tests compression settings against the requested byte target. For general image compression it may also reduce dimensions; PNG and other formats behave differently. The output card reports the actual file size and dimensions, and warns if the target was not met. Inspect the downloaded image for legibility. Encoding is monotonic in quality — a higher setting always produces a larger file — which makes the size search a binary search rather than a scan. The engine predicts the working resolution from the ratio of the original's encoded size to your target, because byte count scales roughly with pixel count; that prediction is what keeps a 12-megapixel phone photograph down to a couple of seconds. If the target is unreachable at any quality, the dimensions are stepped down along a geometric ladder and the path taken is reported. Where a portal enforces a floor as well as a ceiling, standards-compliant padding — a JPEG comment segment or a PNG text chunk — adds bytes that no decoder renders, leaving every pixel untouched. The encoder writes a fresh image rather than editing the original in place, which means colour profile handling is consistent and metadata is dropped deliberately. Quality is chosen by measured search over the encoded output, so the number reported is the actual byte count of the file you are about to download — not an estimate from a table of typical sizes.