Compress an image to 500 KB — 8.4 megapixels, and why 1 MB is better than twice as good

A 500 KB JPG holds 8.41 megapixels of an ordinary photograph — 2367 × 3551 pixels, 511,210 bytes, quality 40.5%. Measured: a 3.33 MB 4000 × 6000 JPEG went into this compressor with a 500 KB target and that is exactly what came out. At 300 dpi those pixels print 7.9 × 11.8 inches, which is a shade narrower and a shade taller than A4.

The interesting part is not the number itself, it is what happens around it. The same photograph at 1,000 KB returns 19.19 megapixels — 2.28× the pixels for 2.00× the bytes. And every single budget from 100 KB to 1,000 KB comes back at the same 40.5% quality, so on this file the byte budget never buys quality at all. It only buys pixels.

Test conditions, so you can weigh these numbers: Chrome 155 on Windows 11, this site's own compressor at crunchimage.com, driven through its published interface on 24 October 2026. Source photograph: a 4000 × 6000 JPEG, 3,492,678 bytes. Each row is one encode, one sample of its content type — not a distribution, and not an average of anything. Where a figure is arithmetic instead of measurement I say so. One source photo means the bytes-per-pixel constant belongs to that photo; the shape of the curve is what transfers, not the constant.

500 KB holds 8.4 megapixels, whatever you start with

The first question people ask is whether a big file compresses "better". It does not, at this budget. Five versions of the same photograph, from 24 megapixels down to 1.5, all pushed to the same 500 KB target:

Six runs, one 500 KB target (512,000 bytes), JPG out. "Untouched" means the tool returned the original 417,234 bytes without re-encoding, because the file was already under the limit and already a JPG. Encode times are single runs and wobble by a second or so between runs.

Four different starting sizes — 12, 13.5, 16 and 24 megapixels — landed inside a 2% band, 8.38 to 8.55 megapixels. The 24-megapixel file did not get a worse deal than the 12-megapixel file; it just had more to throw away. That is the same behaviour the 200 KB page measured at 3.1 megapixels, and it is worth internalising because it kills a common assumption: shrinking the source before compressing does not buy you more pixels at the other end. If you pre-resize a 24 MP photo to 12 MP and then compress to 500 KB, you get the same 8.4 megapixels — but you have thrown away half the detail the encoder could have used to decide where to put them.

Where the ceiling stops biting is between 6 and 12 megapixels. At 6 MP the frame fits whole and the encoder spends the leftover budget on quality — 54.1%, the only photographic row in this table that is not pinned at the floor. So if you have a choice of camera setting and a 500 KB limit, anything at or under roughly 8.5 megapixels arrives intact. Above that, the extra sensor resolution is discarded.

Eleven budgets, one photograph: the whole ladder at 40.5%

The second thing worth measuring is what each additional kilobyte actually buys. Same 3.33 MB photograph, eleven targets from 100 KB to 1,200 KB:

Fourteen runs, one source file (4000 × 6000 JPEG, 3,492,678 bytes), JPG output, targets set in KB where 1 KB = 1,024 bytes. "Extra pixels per extra KB" is the marginal gain over the previous row: pixels gained divided by kilobytes added. Quality is the value the tool reported, identical to five decimal places in every row.

Read the quality column first. It does not move. Every budget from 100 KB to 1,200 KB comes back at 40.47%, which is the compressor's floor — the lowest quality it will accept before it starts cutting dimensions instead. The practical consequence is large: below roughly 1.2 MB, adding bytes to a 24-megapixel photograph buys resolution and nothing else. If you were hoping that 500 KB would look less "compressed" than 200 KB at the same size, this measurement says no. It looks the same; there is simply more of it.

The last row is where that changes. At 1,200 KB the encoder no longer needs to crop: it returned 3993 × 5989, a 0.2% trim that is the search's rounding rather than a real reduction, and still at the 40.5% floor. Somewhere between 1,000 and 1,200 KB the file stops being resized. Above that point extra bytes start buying quality — which is the regime the 1 MB page measured from the other side, where a 16-megapixel photo kept every pixel at quality 48%.

Doubling 500 KB to 1 MB buys 2.28× the pixels, not 2×

Look at the bytes-per-pixel column. It starts at 0.0641 at 1.59 megapixels and ends at 0.0503 at 23.91 megapixels — a 21.5% drop. JPEG's cost per pixel is not a constant, and because it falls as the output grows, the marginal return rises instead of flattening: 15,276 extra pixels per extra kilobyte at the bottom of the ladder, 25,373 near the top, a 66% increase.

That is why the answer to "is 1 MB twice as good as 500 KB" is no, it is better than twice. From 500 KB to 1,000 KB the bytes double (511,210 → 1,022,910, exactly 2.00×) and the pixels go from 8,405,217 to 19,190,605 (2.28×). From 500 KB to 1,200 KB: 2.35× the bytes, 2.85× the pixels, and the whole frame comes back.

I can measure the curve but I cannot tell you from this data alone which mechanism dominates it — the encoder's per-image overhead spread over fewer pixels, or the fact that a heavily downscaled photograph carries a different amount of surviving detail per pixel. What the numbers do establish is that you should not extrapolate linearly. If you know 200 KB gives 3.14 megapixels, the naive guess for 500 KB is 7.85 megapixels; the measured answer is 8.41. The error is 7% at this distance and it grows with the gap.

What 500 KB does to a scan, a text page, flat art, a cutout and a gradient

Content decides the budget, and at 500 KB the spread is wide. Six images, one target, JPG output:

Six runs, one 500 KB target, JPG output, sources as noted (the scan, text, flat, cutout and gradient files were PNG going in). Bytes per pixel is output bytes divided by output pixels — the same sample point on both sides, not source bytes over output pixels.

Three of these rows are more interesting than the headline.

The scanned page is the expensive one. At 0.124 bytes per pixel it costs twice what a photograph costs, so the same 500 KB covers 4.11 megapixels instead of 8.41. A 1655 × 2482 scan of an A4 page is about 200 dpi — legible, but you will see the edges of the letters soften. If the target is a scan, budget for the fact that dense print is the worst case for JPEG, not the best.

The text page is the cheap one, and it keeps everything. A 2400 × 3200 page of text needed only 506,560 bytes at quality 48.4% — no dimension loss at all. Text on white has huge flat areas, and flat areas are nearly free.

Flat art and cutouts get a warning, not a win. Both kept every pixel at 99% quality, and both came back larger than the file that went in: flat artwork 84,394 → 342,896 bytes (4.1×), a cutout 62,081 → 324,148 bytes (5.2×). The tool did the right thing — it stayed under the 500 KB limit — but the PNG it started from was already better than anything JPEG could do with flat colour. Converting was a loss. The same trap, with the numbers behind it, is on the convert to JPG page.

WebP at 500 KB: 15.3 megapixels, and 41 seconds

Same photograph, same 500 KB budget, three output formats:

Three runs, one 500 KB target, one 4000 × 6000 source. PNG has no quality dial in this tool, so the only variable it can spend is pixel count — 1.92 bytes per pixel is what a photographic PNG costs.

WebP buys 83% more pixels for the same bytes, and it buys them at the same reported quality, which makes it the obvious choice if the file is going to a browser and nothing else. Two costs. First, the encode took 41.6 seconds against 9.5 for JPG — 4.4× longer, and on a slow laptop that is the difference between waiting and giving up. Second, WebP is not free at small sizes: a 417,234-byte 1.5-megapixel JPEG converted to WebP at the same 500 KB target came back at 498,828 bytes, 19.6% larger, for no gain you can see. Convert to WebP when you are gaining pixels, not by reflex.

PNG is a different story. On a photograph, the lossless path can only cut pixels: 415 × 623 is 0.26 megapixels, 3.1% of what JPG got from the same budget. On a page of text it does far better — 850 × 1134, 0.96 megapixels, still less than JPG's full 7.68 but no longer absurd. That asymmetry is the same one measured at 100 KB on the PNG page: PNG's cost per pixel depends enormously on whether the picture has detail in it.

500 KB is 512,000 bytes, so use 488 KB for a 500,000-byte form

The tool counts a kilobyte as 1,024 bytes. A 500 KB target is 512,000 bytes, and the photograph came back at 511,210 — 99.8% of the budget, which is the tool doing its job well. But 511,210 is 11,210 bytes over a form that means 500,000, and plenty of upload forms do.

Two runs to find the safe setting:

• Target 488 KB (499,712 bytes) → output 2330 × 3495, 496,595 bytes, quality 40.5%
• Target 489 KB (500,736 bytes) → output 2330 × 3495, 496,595 bytes, quality 40.5%

Identical, to the byte. The dimension search is coarse enough that 488 and 489 KB land on the same step, which is useful rather than annoying: it means the choice is not delicate. Set 488 KB and you clear a 500,000-byte limit with 3,405 bytes to spare, and you give up 37 pixels of width against the 500 KB version (2330 vs 2367, 1.6%).

The 407 KB file that came back untouched

One row in the first table is not a compression at all. A 417,234-byte JPEG at a 500 KB target came back in 0 ms with the same 417,234 bytes and no quality value, because it was already under the limit and already a JPG. The tool passes such files through rather than re-encoding them, which is the correct behaviour — re-encoding would cost quality and could even produce a larger file.

So check the size before you compress. A large share of screenshots, exported web images and phone photos already sit under 500 KB, and for those the only useful action is none. The same pass-through behaviour, at a much tighter budget, is documented on the folder run page.

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

1. Look at the file size first. Under 500 KB and already a JPG? Nothing to do — the tool will return it unchanged.
2. Pick the limit the other side actually means. 500 KB in this tool is 512,000 bytes. If the form says 500,000 bytes or 0.5 MB, set 488 KB and land at 496,595 bytes.
3. Expect 8.4 megapixels for a photograph. If your image is above about 8.5 megapixels it will be scaled to roughly 2370 × 3550. Do not pre-shrink it first; the encoder reaches the same place either way.
4. Leave photographs as JPG. PNG on a photograph at this budget returns 0.26 megapixels. Keep PNG for flat artwork and cutouts, where it keeps every pixel at 99%.
5. Check the quality readout. If it says 40.5%, the budget went into pixels and the file is at the encoder's floor — the same 40.5% you would get at 200 KB. Judge the picture, not the number, at that point.
6. Going up to 1 MB is worth it if you are allowed. It is 2.00× the bytes for 2.28× the pixels, and near 1.2 MB the frame stops being cropped entirely.

When 500 KB is the wrong budget

If the answer you need is a smaller file, this page's own ladder already starts at 100 KB, where the same photograph holds 1.59 megapixels. Below that the same 4000 × 6000 file is measured elsewhere: 50 KB holds 0.78 megapixels (720 × 1079) on the ten-step ladder page, and 200 KB holds 3.14 — which is the ceiling at that budget, not a coincidence, as the 200 KB page shows from four different starting sizes. The 20 KB end is a different regime entirely: the quality floor is hit on every image, the budget is routinely left unspent, and pixels are the only variable left to trade.

If you are going the other way, the 1 MB page covers the budget where photographs up to 19.75 megapixels keep their full frame, and the ladder page walks the same 4000 × 6000 file through ten targets to show where the dimensions stop shrinking and the bytes start buying quality instead.

Questions people ask about 500 KB images

How many pixels is a 500 KB image?

8.41 megapixels for a photograph — 2367 × 3551, measured from a 24-megapixel source, and 8.38 to 8.55 megapixels from 12, 13.5 and 16-megapixel sources. For a scanned page it is 4.11 megapixels, for a text page 7.68 (every pixel), for flat artwork 16 (every pixel). The byte count does not determine the pixel count; the content does.

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

Yes, at 2367 × 3551 — 511,210 bytes, quality 40.5%, 9.5 seconds in the browser. The full 24 megapixels do not survive, because at the measured 0.0608 bytes per pixel they would need about 1.46 million bytes. What you get is an 8.4-megapixel version of the same picture, which prints 7.9 × 11.8 inches at 300 dpi.

Does 500 KB look worse than 1 MB?

At the same display size, yes — but not because of quality. Both are at the 40.5% floor; the 1 MB file simply has 2.28× the pixels, so it holds up better when you zoom or print large. A 500 KB file shown at the size its own pixels support (7.9 × 11.8 inches at 300 dpi) is not visibly worse than the 1 MB one shown at its size.

Is 500 KB enough for a print?

At 2367 × 3551, a 300 dpi print is 7.9 × 11.8 inches — roughly A4. At 200 dpi the same pixels reach 11.8 × 17.8 inches, which is a decent A3. Beyond that you are inventing detail, and at 40.5% quality the fine texture is already gone, so the limit you hit first is the compression rather than the pixel count.

Why did my 500 KB file come back at 511,210 bytes?

Because 500 KB means 512,000 bytes here, and the encoder fills the budget to within 0.2%. It is not an error. If the receiving system counts 1,000 bytes to the kilobyte, set 488 KB instead — that produced 496,595 bytes.

Does WebP fit more into 500 KB?

Yes — 15.34 megapixels against 8.41 for JPG on the same photograph, an 83% gain, at the same reported quality. It costs 4.4× the encode time (41.6 s against 9.5 s) and it can make an already-small file bigger, so use it when you need the pixels, not as a default.

Does the image get uploaded when you compress it to 500 KB?

Not on this site. The file is read with the browser's File API, drawn onto a canvas and re-encoded with canvas.toBlob() inside the page. There is no upload request. Load the page, turn off your network, and the compressor still returns the same bytes.

Every number on this page comes from one photograph and one target at a time. What happens when a whole folder is pushed through at a single fixed limit — ten files, ten outputs, and what one folder-wide setting costs in pixels — is measured on the folder run page.

If your file is a PNG rather than a JPEG, the conversion itself has behaviour worth knowing before you start: it drops the source container, fills transparency with white, and can return a file several times larger. Those outcomes are measured on the convert to JPG page.

At the tight end of the same family, why a JPEG at 20 KB gives up pixels before it gives up quality — and why some images cannot spend the budget at all — is on the JPEG 20 KB page.

And if the limit comes from a portal rather than from you, the three official photo specifications we read line by line are on the portal requirements page.