Home › Guides › Compress to an exact size

How to compress an image to an exact file size

A form says maximum 200 KB and your photo is 4 MB. This is what that limit really means, and how to get under it without ending up with a smear.

Updated 28 August 2026 · 9 min read

On this page
  1. What the limit is actually measuring
  2. The only two dials that matter
  3. What is realistically achievable
  4. How to hit an exact number
  5. When quality alone cannot get you there
  6. Changing the format changes the maths
  7. Two things not to do
  8. A worked example
  9. Doing this to a hundred files
  10. Common questions
  11. Pages already set to a limit

Somewhere between a phone camera that shoots 12 megapixels and a government portal written in 2009, this problem was inevitable. The photo is fine. The form is fine. They simply disagree about how many bytes a picture of a face should take.

What follows is the mechanism, not a list of buttons. Once you know which dial moves what, hitting an exact limit stops being trial and error.

What the limit is actually measuring

A size limit measures bytes on disk. Nothing else. It does not care about the dimensions of your photo, its resolution in DPI, how many megapixels the camera has, or whether the picture is good.

This trips people up because the two most common intuitions are both wrong. Cropping a photo tighter does not reliably shrink the file — you removed pixels, but you may have removed the smooth, easily-compressed sky and kept the detailed, expensive foliage. And changing DPI from 300 to 72 usually changes nothing at all, because DPI is a printing instruction stored in the file header. It is a note that says print me this big. It does not remove a single pixel.

The one that costs people the most time: opening a photo, doing nothing to it, and saving it again — expecting the file to shrink. Re-saving a JPEG at the same quality usually produces a file of roughly the same size, and a picture that is very slightly worse. You paid the toll without crossing the bridge.

The only two dials that matter

Every genuine reduction in file size comes from one of two places.

Dial one: quality

JPEG, WebP and AVIF are lossy formats. They discard information that human eyes are bad at noticing — fine variations in colour, subtle texture in areas that are nearly uniform — and keep what you would actually see. The quality setting decides how aggressive that discarding is.

The number is not a percentage of anything. Quality 80 does not mean “80% of the original picture is left.” It is a position on an encoder's internal scale, and the relationship between that number and the resulting file size is steep and uneven. Dropping from 95 to 85 can halve a file with almost no visible change. Dropping from 50 to 40 saves comparatively little and looks noticeably worse.

That uneven curve is the reason guessing is such a poor strategy, and why a tool that searches for the right value beats a human turning a slider.

Dial two: dimensions

Fewer pixels means fewer bytes, and the relationship is quadratic rather than linear. Halving both the width and the height leaves you with a quarter of the pixels. A 4000 × 3000 photo has 12 million pixels; at 2000 × 1500 it has 3 million.

This dial is blunter but far more powerful, and it is the one people forget. If a limit refuses to be met by quality alone, it is almost always because the image is being asked to stay enormous.

What is realistically achievable

Below are rough landing zones for a normal photograph — a person, a room, a document held up to a camera. Detailed scenes such as foliage, crowds, and fine text compress worse than portraits and flat backgrounds, so treat these as a starting point rather than a promise.

TargetRealistic approachResult
2 MB Quality alone, full resolution Visually identical to the original
500 KB Quality alone, or a mild resize to around 2000 px Indistinguishable on a screen
200 KB Resize to roughly 1200–1600 px, then quality Fine on screen; slight softening if you pixel-peep
100 KB Resize to around 1000 px, quality near 70 Perfectly usable, visibly compressed up close
50 KB Resize to 600–800 px Fine as a thumbnail or avatar, not as a photo
20 KB Only realistic below about 400 px Blocky. Acceptable for icons, not for faces

If a form demands 20 KB and also demands a clearly legible face, those two requirements are in tension, and the form was probably written for a scanner in 2006. Meet the letter of the rule and move on.

How to hit an exact number

There is no formula that converts “I want 200 KB” into a quality setting, because the answer depends entirely on the content of your specific image. A photo of a blank wall and a photo of a forest will land in completely different places at the same quality value.

So the reliable method is a search, not a calculation:

  1. Encode the image at a middling quality and measure the result.
  2. If it came out too large, try lower. If it came out comfortably small, try higher — you are leaving quality on the table.
  3. Repeat, halving the search range each time, until the largest file that still fits under the limit is found.
  4. If the search bottoms out and the file is still too big, reduce the dimensions and search again.

Roughly eight rounds of that narrow the quality setting to within a point. It is dull work for a person and instant work for a machine, which is exactly the kind of task worth handing over.

Compress to a target size → Switch to Target file size, type your limit, and the search above runs automatically — including the resize fallback if quality alone cannot get there. Everything happens inside your browser; the file is never uploaded.

When quality alone cannot get you there

Every lossy encoder has a floor. Push past it and you are no longer trading detail for size — you are producing an image made of visible squares, and the file barely shrinks any further. Compression artefacts have a texture of their own, and that texture costs bytes.

At that point the honest move is to reduce the dimensions. A 1200 px image at quality 82 will look considerably better than a 3000 px image squeezed to the same number of bytes, because the second one is spending its budget describing damage.

Any tool that silently ignores your target, or claims success while handing you a file three times the limit, has simply hidden this decision from you. If a tool reduces dimensions to meet your target, it should say so.

Changing the format changes the maths

The same picture at the same visual quality occupies wildly different amounts of space depending on the format.

FormatRelative size for a photoWorth using when
PNGSeveral times largerNever, for photographs. It is lossless and cannot compete
JPGBaselineAnything that must open everywhere
WebPRoughly a quarter to a third smallerWebsites, and anywhere modern browsers are the audience
AVIFSmaller againWhen you control the audience and can spare the encoding time

The catch is that this only helps if whatever you are uploading to accepts the format. A job portal that wants a JPG will reject a WebP however elegant it is. Read the accepted formats before you optimise for size — it is a common way to lose an afternoon.

Two things not to do

Do not compress an already-compressed file repeatedly. Each pass through a lossy encoder discards a little more, and unlike the first pass, later passes are also busy re-encoding the previous pass's artefacts. Always go back to the original and compress once, harder, rather than compressing a compressed file again.

Do not convert a photograph to PNG hoping for a smaller file. PNG is lossless: it stores every pixel exactly. That is excellent for a logo with twelve flat colours and catastrophic for a photograph with two hundred thousand subtly different ones. Converting a 3 MB JPEG to PNG routinely produces a file of 15 MB or more.

A worked example

Take a typical photo straight off a phone: 4032 × 3024 pixels, about 4 MB, a person standing in a room. The form wants 200 KB. That is a reduction to roughly one twentieth of the original.

Quality alone will not do it while the image stays at 12 megapixels. Even pushed down to a quality setting where the face starts to look plastic, an image that size struggles to reach 200 KB, because there are simply too many pixels each needing at least a few bits to describe.

So the sensible sequence is:

  1. Reduce the dimensions first. At 1512 × 1134 the image has about a seventh of the pixels and is still comfortably sharp on any screen and in most print sizes a form would want.
  2. Then search for the quality. Now the encoder has a realistic job, and it will land near 200 KB at a quality setting high enough that the picture still looks like a photograph rather than a compression exercise.
  3. Check the result at full size, not as a thumbnail. Compression damage hides at small sizes and reappears the moment someone opens the file properly — which is exactly what the person on the other end of that form is about to do.

Doing it in the other order — compressing hard at full resolution, then shrinking the damaged result — produces a visibly worse image at the same file size. The artefacts get baked in and then resized along with everything else.

Doing this to a hundred files

The logic does not change when there are many files; only the patience required does. Two things are worth knowing before starting a batch.

First, a single target applies to each file individually, not to the total. If a portal wants a folder under 20 MB in total and you have forty photos, the per-file budget is 500 KB, and you have to do that division yourself.

Second, batches are where the difference between a fixed quality setting and a target size shows most clearly. A fixed quality applied to forty photos produces forty different file sizes, because a photo of a plain wall and a photo of a market stall compress differently. If a hard ceiling has to hold for every file, the target has to be searched for each one separately — which is tedious by hand and unremarkable for a machine.

Common questions

Does compressing reduce the resolution? Not by itself. Quality-based compression keeps every pixel and describes them less precisely. Only a resize changes the pixel count — though a tool may do both if your target requires it.

Will the person receiving it be able to tell? At quality 80 and above, on a screen, almost never. Printing is less forgiving, because paper resolves detail that a screen does not.

Why did my file get bigger? Usually because the original was already compressed harder than your current setting, or because you changed format to PNG. Compressing at quality 90 a file that was originally saved at quality 70 will grow it, and make it look worse — the worst of both outcomes.

Is there a difference between KB and KiB? Yes, and it occasionally matters at the boundary. 1 KB is 1,000 bytes; 1 KiB is 1,024. Most upload forms mean 1,024 when they say KB, but not all do. If you are landing within a percent of the limit and still being rejected, aim a little lower rather than arguing with the form.

Does removing metadata help? A little, and it is worth doing for other reasons. EXIF data is typically a few kilobytes, though photos with an embedded preview thumbnail can carry considerably more. It will not rescue you from a 4 MB file, but it can win the last few kilobytes at a tight boundary — and it also removes the GPS coordinates you probably did not mean to send.

Pages already set to a limit

If your form named a number, these open with the tool already set to it, so there is nothing to configure.

When the file is a PDF, not an image

The same limits appear on the same forms for documents, and the arithmetic behind them is identical — a storage budget divided by the number of applicants. What differs is what can be given up: a PDF has no single quality dial, because every page has to be rebuilt before it can shrink.

These pages open with the PDF compressor already set to the number a form asked for:

Keep reading