Compress an image to an exact file size
Name a size in KB. The quality that lands under it is found by trying, not by guessing.
How it works
Upload forms impose byte limits because something behind them has a fixed cost. A government portal storing millions of applications caps the attachment at 100 KB to bound its own storage bill; a job board caps a photo at 200 KB because it renders on a page that must load over a slow connection; a school registration system caps at 50 KB because the limit was written into a specification years ago and nobody has revisited it.
The limit is almost always expressed in kilobytes and almost never accompanied by advice on how to reach it. A modern phone photo runs 3 to 6 MB straight out of the camera, so the form rejects it and does not say what to do about it.
Quality is not a size dial
A quality slider is the wrong instrument for this job. Quality is not a proportion of file size; it is a parameter of the encoder's rate-distortion tradeoff, and the curve it traces from quality to bytes depends entirely on the content of the image. A flat studio portrait at quality 60 might land at 40 KB while a photograph of foliage at the same setting lands at 300 KB, because JPEG spends bytes on high-frequency detail and leaves are nothing but high-frequency detail.
The curve is also nonlinear: dropping from 90 to 80 can halve the size, while dropping from 40 to 30 barely moves it. So guessing a number, encoding, checking the result and guessing again is the actual workflow a quality slider imposes, and on a server-based tool each of those iterations is an upload, a wait and a download.
Eight encodes, binary search
This tool does the guessing instead. It decodes your image once, then binary-searches the quality range from 1 to 100. Encode at 50, measure the bytes, go up if there is room and down if there is not; the search keeps the largest result that still fits under the budget. Eight attempts narrow the range to a single quality step, and because every encode runs in WebAssembly on your own machine, eight attempts cost nothing but a second or two of CPU.
In-tab processing is more private, and here it is also categorically better. The search that no server-backed tool can afford to run is free, and the progress bar you see is the real attempt count, not an animation.
When width is the only lever
Sometimes quality alone cannot get there. A 12-megapixel photograph compressed to 20 KB is asking for roughly one byte for every six hundred pixels, and below a certain point even quality 1 produces a file larger than the budget — at which stage the only remaining lever is pixel dimensions, because fewer pixels means fewer coefficients to encode.
The maximum width option is there for that case; halving the width quarters the pixel count and typically cuts the encoded size by a similar factor, with far better-looking results than a quality setting low enough to hit the same number. If the budget cannot be met, this tool says so and reports the smallest file it could actually produce rather than handing you an oversized result and letting the form reject it.
Transparent PNGs come back white
One further caveat for JPEG output: JPEG has no alpha channel, so a transparent PNG cannot stay transparent. Transparent areas are composited onto white before encoding, and a form expecting a photograph wants exactly that; choose WEBP if you need the transparency preserved, and check that the destination accepts WEBP before you do.
Questions
Is my image uploaded to a server?
No. Open your browser's developer tools, switch to the Network tab, and run a conversion. The requests are for this page's code and the WebAssembly encoder; none of them carries your image. The eight encode attempts all happen inside this tab. Tools that do this server-side must upload your file once and then, because each attempt costs them money, hand you back a single guess.
Why is the result 82 KB rather than exactly 100 KB?
Because quality moves in discrete steps and each step changes the size by a jump, not a nudge. The tool keeps the largest encode that fits under your budget, so the answer is always at or below the number you asked for, as a form limit requires. Landing a few kilobytes under is correct behaviour; landing over it would fail the upload.
JPEG or WEBP?
JPEG, unless you know otherwise. Upload forms that specify a size limit almost always specify JPEG or PNG alongside it, and a form that validates by file extension will refuse a WEBP regardless of its size. WEBP reaches a given byte budget at visibly higher quality, typically 25 to 35 percent smaller for the same appearance, so it is the better choice when the destination accepts it.
Can I go the other way and make a file larger?
No, and no honest tool can. Padding an image up to a minimum size means adding bytes that carry no picture, usually junk in a metadata field, which some validators strip and others reject outright. If a form demands a minimum size it is asking for a higher-resolution photograph, not an inflated file.