Get a file under the size a form asks for

Kibibytes, kilobytes and the number on the form

The target size field takes a number of kibibytes. A kibibyte is 1024 bytes, not 1000, so a target of 200 is 204,800 bytes. When a form says 200 KB it may mean the decimal 200,000 bytes, which is about 195 KiB, so read the unit it uses and convert rather than copying the number across.

The difference between the two units is arithmetic, from two constants and nothing else: 1024 bytes to a kibibyte, and 1000 bytes to a decimal kilobyte. Write the limit in bytes first (a decimal 200 KB is 200,000 bytes), then divide by 1024: that is the number this field wants.

Reading it the other way is the same arithmetic with the numbers swapped, and that is the direction that bites. A target of 100 is more bytes than a decimal 100 KB allows, so a file that comes out exactly at that target can still be over the limit you were given. Round the number down rather than up and the file stays under. Nothing here is a saving or a percentage; it is the same two constants either way.

A megabyte on a spec sheet is not always decimal either. If the sheet defines its own MB in 1024-byte units, then a 1 MB limit is 1024 KiB, and 1024 is what this field takes. Where a sheet gives a number and no unit at all, the ambiguity belongs to the sheet rather than to the tool, and the finished row is what settles it: it shows the size before and the size after in KiB, the unit this field takes, so a KiB limit can be read straight off it. For a decimal limit, compare the row with the right-hand column of the table, or read the downloaded file’s size in bytes.

A target is a ceiling with a band under it

This is the difference that matters most on this page. A target is a limit the output must be at or under, not a size the tool will produce. The tool encodes at your quality setting first, then searches for a quality whose output fits under your number, in one direction or the other.

When the first encode is over the target, the search lowers quality, as far as 1 at the lowest, until the file fits. When the first encode comes out well under the target, the search goes the other way: upward from your setting, never past 100, for the highest quality that still fits. Only that upward search is bounded by your setting. Lowering it is how the tool reaches your number, so a file that was over the target can come back rougher than the quality you chose.

The search aims at a band: at most your number, and at least 95% of it. Quality moves in whole numbers, and one step can jump across the whole band, so the file lands inside it when a step falls inside it and is the closest encode under your target when no step does. That is the honest shape of the guarantee. When a quality fits, the file is at or under your number; it is not a promise that it lands just under your figure, or within 5% of it.

A target above what the format can produce at all is a case worth naming. The quality scale stops at 100, so a target far larger than the picture’s own best encoding cannot be filled by making the file bigger. There you get the largest file the format made, which is still under your number, and the row reports the target as reached, because the file is at or under the ceiling. The row’s verdict is taken on the bytes you actually download, counted after any EXIF you asked to keep, so you are never told a limit was met when the file on your disk is over it.

Which sizes a quality setting can reach, and which need a resize first

Quality is the only knob the search spends, so whether your number is even possible has an honest answer with more than one part to it. The ordinary case: a smaller ceiling is only a narrower band to land in. The search lowers quality from your setting, as far as 1 at the lowest, until the file fits, and fills upward from your setting when the first encode comes out far under your number.

Three cases come out differently from that ordinary one, and each has its own answer.

A picture that is still over the target at quality 1 does not reach it. Quality 1 is the floor of the scale, so there is no lower setting left to spend, and the row reports the miss. What is left to spend is pixels.

A PNG cannot spend the search at all, because it is lossless and quality is not its knob. There is a section on that case on its own below.

A kept EXIF block is written after the search rather than inside the budget the search worked to, so a file that fitted can still come out over the ceiling once you switch metadata keeping on. Leave that control off when a hard limit matters, which is also the default.

A ceiling above what quality 100 produces is not a failure either: you get the quality 100 encode, which is still under your number, and the row says the target was reached. The section above sets that case out in full.

So the order that works is the same in every case: set a width with the resize control and keep the target in the same run, because the tool resizes first and then searches quality on the smaller picture. Half the width is a quarter of the pixels, and the size falls with the pixels, while quality only changes what each pixel costs. The output format moves the number too, and the WebP page covers that choice, including the fact that a JPEG output flattens transparency onto white before it encodes.

When the row says the target was missed

A miss is worth reading before you try again. It was decided on the file you download rather than on the encode that came close, so a file the search nearly landed will be reported as over the limit when it is.

There are three honest reasons for a miss.

Resize in the same run: set a width with the resize control and leave the target where it is. Quality 1 is the floor of the search, so a file that misses there cannot be fixed by lowering quality any further, and fewer pixels can fix it because the size falls with them.

When you switched on keeping metadata, the EXIF block is written after the search, so a file that fitted can come out over the ceiling. Switch the control off and run again before you resize.

If the file is a PNG, the search never ran at all, so there is no second attempt to wait for and nothing to tune. The section below covers what a PNG can and cannot do.

When you do keep the result, judge it by the two previews the row gives you, the picture you chose beside the one you are about to get. That comparison is how you decide whether the file is worth having at that size.

A PNG under a size limit

PNG is lossless, so it ignores the quality setting entirely, and that is the whole reason a target on a PNG behaves differently from a target on a JPEG. There is no dial to turn down, so the search has nothing to spend: a PNG whose first encode is over your number gets no quality step, and only the optimizing pass below can still bring it under.

There is one more pass, and it is worth knowing about. Every PNG output goes through a second optimizing pass, and its bytes are kept only when they are fewer than the first encode’s. So a PNG can come back smaller and can land under a target the first encode missed, and it can equally fail to. Nothing here makes that pass hunt for your number: it either returns fewer bytes or it does not.

That leaves two honest routes to a smaller PNG. Fewer pixels work in any format, so a resize first is the first thing to try. A lossy output format works too, and there the quality search has a knob to spend, so converting the PNG to WebP is the answer when the ceiling sits far below what a lossless file of that picture can reach. It is a trade rather than a free win: what the encoder gives up to reach the number is yours to look at in the preview before you keep the file.

Keeping metadata adds bytes after the search

This is a subtlety that catches people out. The size search runs before any EXIF block is written, because the encoders write none by default and the block is added at the very end when you ask to keep it. The block is therefore not in the budget the search worked to.

The tool handles this honestly rather than quietly: it counts the final bytes, including the block, so if keeping the metadata pushes the file over your target the row reports the target as missed even though the encode on its own was under it. Leave the keep control off when a hard limit matters, which is also the default.

Reading the verdict

Every finished row carries one of two statements when you set a target: that the file is at or under it, or that it is not. Read it rather than assuming. The run never reports a target it missed as reached, so a row saying it was missed means the file on your disk is over the limit. The section on misses above says which change can fix it.

If a file is refused

An input larger than 32 MiB is refused from its size alone, before its bytes are read. An input over 40,000,000 pixels is read, then refused before anything decodes it, because the pixel count is only known once its header has been parsed. Both numbers are fixed rather than a reading of your machine. The refused file names the limit that refused it, and every other file in the run still finishes.

What to do next

Set the target in KiB, read the verdict, and if it was missed, resize the picture and run it again rather than lowering quality further. When the ceiling came from a form or a portal rather than from your own choice, the photo limits page reads that spec sheet and says which part of it this tool can meet. If your work is mostly photographs, the compress JPEG page covers the quality side in more detail, and if the format is the open question the WebP page covers that.