How do I get an image under a specific file size?
Encoders take a quality setting, not a size, and the resulting bytes depend on image content. Hitting a target requires encoding repeatedly at different qualities and keeping the largest result that fits, which is what a target-size tool automates.
Updated 2026-08-24
Why you cannot just ask for 200 KB
Upload forms specify a maximum file size, image encoders accept a quality setting, and there is no direct relationship between the two. Understanding why explains what any target-size tool is actually doing.
A lossy encoder works by discarding detail the eye is poor at noticing, and the quality parameter controls how aggressively. What it does not control is the output size, because how many bytes remain depends entirely on how much detail the image contained to begin with.
The effect is large. A photograph of foliage or gravel — thousands of small high-contrast details, none of them predictable — might encode to 800 KB at quality 80. A flat product shot on a white background, the same pixel dimensions and the same quality setting, might encode to 40 KB. Twenty times the difference from identical settings, because one image has twenty times the information in it.
So a tool cannot compute the quality needed for a target size. It has to encode, measure, and try again. The standard approach is a binary search: encode at the midpoint of the quality range, check the size, and move the search window up or down accordingly. Around eight iterations narrows a range of a hundred quality levels to a single value, and because encoding a typical photograph takes a few milliseconds, the whole search finishes fast enough to feel instant.
The important detail is which result to keep. The correct answer is the largest output that still fits under the limit, not the first one that fits — landing at 60 KB against a 200 KB limit means throwing away quality the limit would have allowed. A tool that stops at the first success is leaving a lot on the table.
Reduce dimensions before you reduce quality
This is the single most effective thing to do and the step most often skipped, because the size problem presents as a compression problem.
File size scales roughly with pixel count, and pixel count scales with the square of the dimensions. Halving both width and height quarters the pixels, and typically lands somewhere near a quarter of the file size at unchanged quality. Reaching the same reduction by lowering quality alone means pushing into the range where compression artefacts become plainly visible.
The question worth asking first is what the image is for. A photograph destined for a web page rendered at 800 pixels wide gains nothing from being 4,000 pixels wide; the browser scales it down and the extra data is discarded on every single page load. A document upload displayed at a few hundred pixels needs even less. Phone cameras now produce twelve megapixels or more by default, and the overwhelming majority of images are eventually viewed at a small fraction of that.
The exception is anything that will be printed, cropped or examined closely. Print at 300 dots per inch needs about 2,500 pixels across for a letter-sized page, and an image that might be cropped needs the extra pixels in reserve. Where the destination is unknown, resizing to something like twice the expected display size is a reasonable compromise.
The order matters: resize first, then compress. Encoding a large image and then scaling the result down wastes the compression work and can make artefacts more visible, because the artefacts get scaled along with the content.
Which format to land in
The format choice can matter as much as the quality setting, and the right answer depends on the image rather than on a general ranking.
For photographs, WebP is generally the smallest of the widely supported options at equivalent visual quality, commonly landing twenty-five to thirty percent below JPEG. It has been supported in every major browser for years. The reason not to use it is when the destination is not a browser: some upload forms, document systems and older desktop software still reject or mishandle it, and an upload rejected for its format is worse than one that is slightly larger.
JPEG remains the safe default for photographs where compatibility is uncertain. It is universally accepted, and at moderate quality settings the difference from WebP is not visible without comparing side by side.
PNG is the wrong format for a photograph and people reach for it constantly, because it is lossless and lossless sounds better. Lossless means it must reproduce every pixel exactly, including all the sensor noise, so a photograph saved as PNG is frequently several times larger than the same image as a JPEG at quality most people cannot distinguish from the original. PNG is for what it was designed for: flat colour, sharp edges, screenshots of text, and anything needing transparency.
HEIC is what recent iPhones capture by default, and it is efficient — roughly half the size of JPEG at similar quality. Its problem is acceptance. A great many websites, forms and Windows applications cannot read it, which is why converting to JPEG is such a common first step. That conversion usually increases the file size, which surprises people, and it is the price of the file being readable at all.
What to watch for in the result
A file that meets a size limit can still be the wrong file, and a few checks take seconds.
Re-encoding a lossy image compounds its losses. Every JPEG save discards detail, and the discarded detail never comes back, so an image opened and saved repeatedly degrades cumulatively even at high quality settings. Where an original exists, compress from the original rather than from a previously compressed copy.
Transparency does not survive a move to JPEG, which has no alpha channel. A logo with a transparent background converted to JPEG gains a background — usually white, sometimes black, and whichever it is will be wrong somewhere. Anything needing transparency has to stay in PNG or WebP.
Metadata is worth a thought in both directions. Stripping EXIF removes camera information and, importantly, GPS coordinates, and it also recovers a few kilobytes, which occasionally is the few kilobytes needed. But it removes the orientation flag too, and an image whose rotation lived in that flag will appear sideways afterwards unless the tool applies the rotation to the pixels before discarding it.
Finally, look at the output at full size before sending it. Compression artefacts concentrate around sharp edges and text, so an image that looks fine as a thumbnail can have visibly mangled lettering. Where an image contains text, that is the part to check first.