ExactSize

Compress image to 200KB — and where 200KB stops costing you resolution

A 200KB JPG holds about 3.1 megapixels of an ordinary photograph — 1447 × 2170 pixels, which is a 5.1 inch print at 300 dpi. Measured, not estimated: a 3.33 MB 4000 × 6000 JPEG run through this compressor with a 200 KB target came back at 1447 × 2170 px, 203,474 bytes, quality 40.5%. A 6-megapixel photo came back at 1432 × 2148 — the same 3.1 megapixels from a quarter of the input, which is why that number is a ceiling and not an accident.

The short answer

At 200 KB the answer depends on whether your image is above or below that ceiling:

  • Photograph above 3.1 MP: dimensions get cut to about 1440 × 2150 (3.1 MP)
  • Photograph at or below 1.5 MP: keeps every pixel, at quality 75%
  • Page of text: 957 × 1436 to 1215 × 1621 (1.4–2.0 MP)
  • Flat artwork: keeps all 16 MP, at quality 84%
  • Smooth gradient: keeps all 3.84 MP, at quality 86%

Twelve runs, one 200 KB target. Three of them kept every pixel — that is what makes 200 KB a different question from 20 KB, where the quality floor is hit every single time.

How to read these numbers: twelve separate encodes of this site's own compressor, each one a single sample of its content type — not a distribution. Every figure is what the tool actually returned, read from its own result panel. Where a number is arithmetic instead of measurement, I say so and show the division. For the same question at a much tighter budget, the measured pixel counts at 20 KB are on the 20 KB page.

How these numbers were measured

Test conditions, so you can decide how far they apply to your file: Chrome 155 on Windows 11, the compressor served from this site, twelve source images, one target of 200 KB set through the tool's own target field. Each run loaded a fresh copy of the page, set the file, set the format, pressed Compress image and waited for the result panel. Nothing was computed from a formula first — the byte counts and dimensions below are what the encoder handed back.

The sources were a 24-megapixel photograph and three downscaled copies of it at 6, 1.5 and 0.38 megapixels; a 24-megapixel scanned page; a 7.68-megapixel text page; a 16-megapixel flat artwork; a 12.96-megapixel cutout with transparency; and a 3.84-megapixel gradient. The same 24-megapixel photo was also run as WebP, and the text page as PNG, to compare formats at the same budget.

One thing about this compressor matters for every table here: it holds your pixel dimensions and trades quality away only down to 40%. Below that it reduces the picture instead. At 20 KB that floor is reached in every run. At 200 KB it is reached only when the image is too big to fit at 40% — and that is exactly what the first table shows.

A photograph at 200 KB: four starting sizes, one output size

Same photograph, four starting resolutions, one 200 KB target. This is the table that answers the practical question, because most people arrive with a phone photo far above 3 megapixels.

Source Source size Output at 200 KB Megapixels Output bytes Quality Time
4000 × 6000 3.33 MB 1447 × 2170 3.14 203,474 40.5% 24.8 s
2000 × 3000 1.43 MB 1432 × 2148 3.08 204,289 40.5% 3.9 s
1000 × 1500 407 KB 1000 × 1500 1.50 203,896 75.2% 1.0 s
500 × 750 103 KB 500 × 750 0.38 104,988 unchanged 0 ms

Two of the four runs returned almost the same pixel count — 3.14 and 3.08 megapixels — from inputs that differ by a factor of four. That is the ceiling showing itself. The third run did not scale at all: a 1.5-megapixel photo fits inside 200 KB comfortably, so it kept every pixel and the encoder only spent quality, landing at 75.2%. The fourth run never encoded anything: 103 KB is already under 200 KB and already a JPEG, so the tool passed the file straight through in 0 ms, byte-identical.

Where the quality floor stops biting

This is the part that makes 200 KB worth its own page. At 20 KB every output comes back at 40–43% quality, because the tool has run out of quality to spend and starts cutting pixels instead. At 200 KB that is no longer automatic:

  • 1000 × 1500 photo: quality 75.2%, dimensions untouched.
  • 2000 × 3000 photo: quality 40.5%, dimensions cut to 51%.

So somewhere between 1.5 and 6 megapixels, 200 KB stops being a comfortable budget and becomes a tight one. Above that line the encoder behaves exactly as it does at 20 KB — it hits 40% and starts shrinking. Below the line you get something you never get at 20 KB: full resolution, at a quality level that still looks like a photograph rather than a thumbnail.

In practice this is the difference between "I compressed it" and "I destroyed it". A 1.5-megapixel photo at 75% is a usable image. The same photo forced to 40% at half the dimensions is not.

The ceiling is about 3.1 megapixels, and it is arithmetic as well as measurement

The two runs that hit the floor give the price of a pixel at 40% quality. Divide the output bytes by the output pixels:

  • 203,474 bytes ÷ 3,139,990 pixels = 0.0648 bytes per pixel
  • 204,289 bytes ÷ 3,075,936 pixels = 0.0664 bytes per pixel

Those two sampling points sit 2.4% apart, so 0.0655 bytes per pixel is a fair working figure. Now divide the budget by it: 204,800 bytes ÷ 0.0655 = 3,127,000 pixels, or 3.13 megapixels. That is the measured 3.08–3.14 megapixels arriving from a completely different direction, which is why I am comfortable calling it a ceiling rather than a data point.

Turned around, a photograph at 200 KB buys about 15,400 to 15,800 pixels per KB. That number is what you want in your head before you decide whether 200 KB is enough for the dimensions a form is asking for.

Content decides again: text, flat art, cutouts, gradients

The photograph ceiling is not a universal ceiling. Five content types, one 200 KB target, all JPG:

Content Source pixels Output at 200 KB Megapixels Output bytes Quality Pixels per KB
Scanned page 24.00 MP 957 × 1436 1.37 203,709 41.4% 6,908
Text page 7.68 MP 1215 × 1621 1.97 204,768 40.5% 9,849
Flat artwork 16.00 MP 4000 × 4000 16.00 204,121 84.1% 80,266
Cutout 12.96 MP 3600 × 3600 12.96 186,314 99.1% 71,229
Gradient 3.84 MP 2400 × 1600 3.84 196,891 85.5% 19,971

The spread is 11.6× — 6,908 pixels per KB for a scanned page against 80,266 for flat artwork. Text is the expensive content type because every letter edge is high-frequency detail; flat colour is nearly free because a run of identical pixels costs almost nothing after compression.

Notice what the flat artwork, the cutout and the gradient have in common: none of them scaled at all. The flat artwork kept 16 megapixels — four times the photograph ceiling — at 84% quality. The cutout kept 12.96 megapixels at 99.1%, which means the encoder barely touched it: a 61 KB PNG source re-encoded as a 186 KB JPEG, and it still fits, because there is almost no detail in a shape on a plain background. If your image is a logo, a diagram or a screenshot of a form, 200 KB is not a constraint at all.

One caveat on the cutout: the source had transparency, and JPG has no alpha channel. It came back at 99.1% quality, but the transparent background is now solid white. If the transparency has to survive, the format choice matters more than the byte budget.

WebP and PNG at 200 KB

Two formats, three runs, same 200 KB target:

Source Format Output at 200 KB Megapixels Output bytes Quality
4000 × 6000 photo WebP 1781 × 2671 4.76 204,336 40.9%
1000 × 1500 photo WebP 1000 × 1500 1.50 204,284 80.3%
2400 × 3200 text page PNG 490 × 653 0.32 202,529 lossless

WebP buys 51% more pixels at the same 200 KB on the 24-megapixel photograph: 4.76 megapixels against JPG's 3.14, at the same 41% quality. On the smaller photo it bought quality instead — 80.3% against 75.2% at identical dimensions. Either way it is the same trade, and if the destination accepts WebP there is no reason to choose JPG at this budget.

PNG is the opposite story. The 7.68-megapixel text page as PNG came back at 490 × 653 — 0.32 megapixels, a fifth of what JPG managed from the same source — because PNG is lossless and cannot spend quality. At 0.633 bytes per pixel it needs roughly ten times the bytes JPG needs for the same pixels. A 200 KB PNG budget is not a compression budget; it is a "how small must the picture be" budget.

200 KB is 204,800 bytes, and that matters

The tool reads 200 KB as 204,800 bytes, and it honours that exactly: nine of the twelve outputs landed between 203,474 and 204,768 bytes. Every one of those is under 204,800 and above 200,000.

So if the form you are uploading to means 200,000 bytes when it writes "200 KB", nine of these twelve files would be rejected. The arithmetic for a safe target is simple: 195 KB × 1,024 = 199,680 bytes, which clears a 200,000-byte limit with 320 bytes to spare. Set 195 KB, not 200 KB, when you are not sure which definition the portal uses.

The three outputs that would pass a 200,000-byte limit as they stand are the pass-through (104,988), the cutout (186,314) and the gradient (196,891) — and those passed because they had room to spare, not because the tool aimed lower.

How to compress an image to 200 KB, step by step

  1. Open the compressor. It runs in the page; there is no sign-up and no upload.
  2. Drop your image on the box, or click it to pick a file. JPG, PNG, WebP, GIF and BMP all load.
  3. Click the 200KB preset, or type 195 if the destination counts a kilobyte as 1,000 bytes rather than 1,024.
  4. Choose WebP if the destination accepts it — it fits 51% more pixels here. Choose JPG for photographs when it does not, and PNG only for flat artwork, diagrams or anything that must stay lossless.
  5. Press Compress image. The result panel reports the output dimensions, the output bytes and a one-line verdict telling you whether the dimensions were kept or scaled — and, when they were scaled, why.
  6. Read that verdict before you download. If it says "dimensions scaled", check the megapixel figure against what you need. A file that is under 200 KB but 950 pixels wide will fail a form that asks for 1200 × 1600, even though the byte count is perfect.

When 200 KB will not hold the dimensions you need

At roughly 15,600 pixels per KB for a photograph, 200 KB is a 3.1-megapixel budget. If a form demands 200 KB and also demands 3000 × 2000 (6 megapixels), no compressor can satisfy both from a detailed photo — the pixels are not there. The realistic options, in order:

  • Switch to WebP if accepted: 4.76 megapixels instead of 3.14 at the same 200 KB, measured above.
  • Crop before compressing. A tighter crop spends the budget on the subject instead of the background. This is the only way to keep detail at a fixed byte count.
  • Flatten the background. A busy background costs more than the subject. The flat artwork run held 16 megapixels at 84% quality in the same 200 KB — that is what removing detail from the background buys you.
  • Check whether the limit is really 200 KB. Plenty of forms say 200 KB and accept 2 MB, or apply the limit only to a thumbnail.

If you arrived here from the other direction — a 20 KB limit, not 200 KB — the same photo that holds 3.1 megapixels here holds 0.3 megapixels there, and that page shows the measured numbers for what 20 KB actually holds. If the constraint is a specific portal rather than a byte count, the three government photo specs I read and the 100 KB-versus-102,400-byte trap are on the portal rules page.

Questions people ask about 200 KB images

How many pixels is a 200 KB image?

About 3.1 megapixels for a photograph — 1447 × 2170 measured from a 24-megapixel source, and 1432 × 2148 from a 6-megapixel source, which is the same answer twice. For a page of text it is 1.37 to 1.97 megapixels, for flat artwork all 16 megapixels survived, and for a gradient all 3.84 megapixels did. The byte count alone does not determine the pixel count; the content does.

Can a 4000 × 6000 photo be compressed to 200 KB?

Yes, at 1447 × 2170 — 203,474 bytes, quality 40.5%, 24.8 seconds in the browser. The dimensions do not survive, because 24 megapixels at the measured 0.065 bytes per pixel needs about 1.5 MB. What you get is a 3.1-megapixel version of the same picture.

Does compressing to 200 KB always reduce the dimensions?

No. Four of the twelve runs kept every pixel: the 1.5-megapixel photo (75.2% quality), the 16-megapixel flat artwork (84.1%), the 12.96-megapixel cutout (99.1%) and the 3.84-megapixel gradient (85.5%). Only images that needed more than about 3.1 megapixels of a photograph's detail budget were scaled down.

Is a 200 KB file good enough to print?

At 1447 × 2170, a 300 dpi print is 4.8 × 7.2 inches — a 5 × 7 print with a little margin. At 150 dpi the same pixels reach 9.6 × 14.5 inches. Above that you will see the compression, not the resolution: the file is at 40.5% quality, so fine texture is already gone.

Why did my 200 KB file come back larger than 200,000 bytes?

Because the tool measures a kilobyte as 1,024 bytes, so 200 KB is 204,800. Nine of the twelve outputs landed between 203,474 and 204,768. Set 195 KB (199,680 bytes) when the portal on the other side counts 1,000 bytes to the kilobyte.

Does the image get uploaded anywhere?

Not on this site. The file is read with the browser's File API and re-encoded on a canvas inside the page. Load the page, disconnect your network, and the compressor still returns the same bytes.

The 200 KB numbers above are one file at a time. What happens when a whole folder is pushed through at a fixed limit — ten files, ten different outputs, and what a single folder-wide setting costs in pixels — is measured on the folder run page.

If your starting file is a PNG rather than a JPEG, the conversion itself has behaviour worth knowing: it discards the source container, fills transparency with white, drops the EXIF block, and can return a file larger than the one you put in. Those four outcomes are measured on the convert to JPG page.

For the same photo at every budget from 2,400 KB down to 20 KB — where the dimensions stop shrinking and the bytes start buying quality instead — the ten-step ladder is on the 4000 × 6000 ladder page.