Compress an image to 300 KB — 4.84 megapixels, and what the next 200 KB actually buys

A 300 KB JPG holds 4.84 megapixels of an ordinary photograph — 1796 × 2694 pixels, 306,526 bytes, quality 40.5%. Measured: a 3.33 MB 4000 × 6000 JPEG went in with a 300 KB target and that is exactly what came out, 674 bytes under the 307,200-byte ceiling. That is 16,128 pixels per kilobyte, or 0.0634 bytes per output pixel.

The number that decides whether you should care is not the 4.84. It is this: going from 300 KB to 500 KB added 66.8% more bytes and 73.7% more pixels, and reduced the measured difference from the original by only 15.3%. Nine budgets on one photograph, every output rendered into the same 1600 × 2400 frame, put a number on something that is usually argued about instead of measured.

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 25 October 2026. Source photograph: a 4000 × 6000 JPEG, 3,492,678 bytes. One encode per row, one sample of each content type — not a distribution, and not an average of anything. The error column is measured, not modelled: for each of the nine ladder rows the output was drawn into a 1600 × 2400 canvas beside the original and the absolute difference was taken per channel on a 0–255 scale. Outputs larger than that frame are downscaled into it, which is deliberate — the frame asks what a viewer sees at that size, not what a 100% zoom reveals. Where a figure is arithmetic rather than measurement, the text says so.

300 KB is 307,200 bytes, and the output landed at 306,526

The first thing to settle is the unit, because it decides whether a form accepts the file. This compressor counts a kilobyte as 1,024 bytes, so a 300 KB target is 307,200 bytes and the photograph came back at 306,526 — 674 bytes of headroom. Plenty of upload forms mean 300,000 bytes when they write "300 KB", and 306,526 fails that by 6,526.

Setting the target to 293 KB instead returned 298,593 bytes at 1773 × 2660, which clears a 300,000-byte limit with 1,407 bytes to spare and costs 2.5% of the pixels. The same trap at 500 KB needs 488 KB, and at 100 KB the tool overshoots by 1,000 bytes or more, which is why the 100 KB page treats the 100,000-versus-102,400 split as its main subject rather than a footnote.

Nine budgets on one photograph, and what each 100 KB recovers

One source file, nine targets from 100 KB to 800 KB, JPG output every time. The dimensions and the quality figure are what the result panel reported. The error columns are the measured difference from the original at a 1600 × 2400 frame.

Two things stand out. The first is that quality never moves. Every budget from 100 KB to 800 KB comes back at 40.47%, because the encoder searches quality down to a 40% floor and then spends whatever is left on pixels. So on this file the budget does not buy quality at all — it buys area, and only area. That is the same behaviour the 20 KB JPEG study found at the tight end, where 89 of 102 measured runs reported 40.5%.

The second is that the pixel count is almost exactly proportional to the budget. Every 100 KB step adds between 1.55 and 1.84 megapixels up to 600 KB, and 2.07 megapixels on the last stretch to 800 KB, because at a fixed quality JPEG costs a nearly fixed number of bytes per pixel and that cost drifts slightly downward as the frame grows. 4,838,424 pixels ÷ 300 KB = 16,128 pixels per kilobyte. If you want to predict a neighbouring budget on your own file, that is the constant to start from — then check it, because a scan is not a photograph and the constant is not portable.

Each doubling of the budget removes about 18% of the error

Proportional pixels do not mean proportional visible quality. Doubling the bytes and measuring the result at the same viewing frame gives four pairs from the same ladder:

That is the useful shape of the curve, and it is not what most advice implies. There is no knee, no cliff, no budget above which the picture "stops improving". There is a steady 16% to 21% reduction per doubling, averaging 18%, and it holds across the whole range. The first doubling is worth about as much as the fourth. What changes is the absolute size of the thing being reduced: at 4.58 levels of error you are cutting into visible difference, at 2.51 you are cutting into something already close to invisible.

For scale, a mean absolute error of 3.29 across the channels is roughly a 1.3% average shift per channel. That is not nothing — you can find it in a smooth gradient if you put the two images side by side — but it is far below the point where a photograph looks wrong on its own.

What the next 200 KB buys: 74% more pixels, 15% less error

The comparison people actually face is not 300 KB against 800 KB, it is 300 KB against the 500 KB limit somewhere else in the same workflow. From the ladder:

That last line is the interesting one, and it is why the 300 KB answer is not simply "worse". The average error barely moves, but the share of badly wrong samples halves. The extra 200 KB is not making the whole picture better; it is repairing the places where compression was visibly failing — edges, fine texture, anything with high local contrast. If your image is a portrait against a plain background, those places are few and 300 KB is close to indistinguishable from 500 KB. If it is a landscape with foliage in it, they are everywhere, and the halving of the tail is the part you notice.

So the decision rule is not about the budget, it is about the content: buy bytes when the picture has detail at the pixel level, skip them when it does not. The 500 KB page follows the same ladder upward and shows that doubling again from 500 KB to 1 MB returns 2.28× the pixels for 2.00× the bytes — the same proportional gain in area, measured from the other end of the ladder.

Eight content types at 300 KB, and quality from 40.5% to 99.1%

The 40.5% figure is a property of this photograph, not of the budget. Feed the same 300 KB target a simpler picture and the encoder stops long before the floor, because there is nothing left to spend the bytes on:

The spread in the last column is 9.8×, from 0.0144 bytes per pixel for a cutout to 0.1411 for a scan. The scan needs ten times the bytes per pixel that a cutout does, which is why a 300 KB budget buys a scanned page 2.17 megapixels and a piece of flat artwork all 16 million of its pixels. This is also why no single "300 KB = X megapixels" rule survives contact with real files: the number is a property of the picture's detail, and the budget only sets the total.

Notice what the bottom two rows did. Both sources were already far under the limit — 84 KB and 62 KB — and the result panel said so in as many words: "The source was already inside the limit." It re-encoded them to JPG anyway, because JPG was the requested output format, and it searched quality upward until the budget was nearly full. That is the next section.

The 84 KB PNG that came back at 291 KB

This is the least obvious failure mode at 300 KB, and it is entirely reproducible. A 4000 × 4000 flat artwork PNG of 84,394 bytes — already 72% under the limit — went in with JPG selected as the output format and came back at 297,850 bytes. That is 3.53× larger than the file that went in. The cutout went from 62,081 to 186,314 bytes, 3.00× larger.

Nothing went wrong. The tool was told to produce a JPG at a 300 KB target, and it did: it kept every pixel and raised quality to 97.2% and 99.1% to use the space it was given. The mistake was asking for the conversion at all. A PNG that is already under the limit does not need to be compressed, and converting it to JPG at a large target gives the encoder a budget it will spend.

The same asymmetry shows up at the other end of the family: the conversion page measured the same kind of re-encode at a 20 KB target, where the budget is too small rather than too large, and found that the conversion deletes things — the alpha channel, and in some cases most of the frame. Same operation, opposite failure, and the rule that covers both is: convert only when the format is the problem.

WebP at 300 KB: 61% more pixels, 2.7× the wait

The same 4000 × 6000 photograph at the same 300 KB target, encoded as WebP instead of JPG, came back at 2278 × 3417 — 7.78 megapixels against 4.84. That is 60.9% more pixels for the same byte budget, and both outputs sat on the same 40.5% quality floor, so the gain is real and not a quality trade.

The cost is time and compatibility. The result panel reported 35,149 ms for the WebP encode against 12,908 ms for the JPG at the same target in the same session — 2.7 times the wait, on one 24-megapixel file. And a WebP file is still rejected by a fair number of upload forms that say "JPG or PNG only", which turns a 61% pixel gain into a failed submission.

If the form means 300,000 bytes, set 293 KB

Two numbers, measured on the same file, one target apart in intent:

• 300 KB → 306,526 bytes at 1796 × 2694. Passes a 307,200-byte limit. Fails a 300,000-byte limit by 6,526 bytes.
• 293 KB → 298,593 bytes at 1773 × 2660. Passes a 300,000-byte limit with 1,407 bytes to spare.

The cost of the safe choice is 1.3% of the width and 2.5% of the pixels. If you do not know which convention the form uses, use 293 KB — it passes both, and the pixels you give up are inside the range where the error curve is flat anyway.

How to compress an image to 300 KB

1. Decide what 300 KB means. If the limit is written as 300,000 bytes, enter 293 in the target field with KB selected. If it is 307,200, enter 300.
2. Leave the format alone for photographs. A photograph converted to PNG at 300 KB came back at 319 × 478 — a lossless encode can only shrink by losing area. Keep JPG.
3. Read the quality line first. At 40.5% the encoder hit its floor and spent the budget on pixels; at 76% or above the whole frame fitted and the budget went into quality. The second case means you have room to spare.
4. Check the pixel count against the content. A photograph should land near 4.8 megapixels; a scan near 2.2; a page of text near 3.7. If a photograph lands far below 4.8, the source was probably already a low-quality re-encode and the budget is being spent repairing it.
5. Stop at 300 KB unless the detail is there. The next 200 KB buys 73.7% more pixels and 15.3% less average error. Worth it for foliage, fabric and text; not worth arguing about for a portrait on a plain background.

When 300 KB is the wrong budget

When the source is already small. A 1.5 MP photograph came back at 261,968 bytes and quality 83.1% in 315 ms — it never needed compressing, and a smaller target would only cost quality for bytes nobody asked for.

When the image is flat. Flat artwork used 297,850 bytes to keep 16 megapixels at 97.2% quality; the cutout could not spend the budget at all and stopped at 186,314 bytes with 118 KB unused. A 300 KB limit on flat art is not a constraint, it is a ceiling the file cannot reach.

When the content is text at small size. A page of text lost 51% of its pixels at this budget and sat on the 40.5% floor, because print detail costs 0.0822 bytes per pixel — 30% more than a photograph. If the output has to stay readable, a larger budget or a two-step approach works better than forcing 300 KB.

When the limit is a portal's, not yours. The official photo specifications we read line by line — UK, New Zealand, Canada — do not use 300 KB as a ceiling at all, and one of them sets a 250 KB minimum. That is worth checking before you compress anything: the portal requirements page has the figures with their source URLs and the date they were read.

Questions this page gets

How many megapixels is a 300 KB image?

4.84 megapixels for an ordinary photograph — 1796 × 2694 at quality 40.5%. But it is a ceiling, not a conversion factor: a 6-megapixel photograph kept all 6 megapixels at 76.1% quality, and a 1.5-megapixel one kept all 1.5 at 83.1%. The budget sets the bytes; the picture's detail sets how many pixels those bytes cover.

Is 500 KB twice as good as 300 KB?

No, and the gap is wide. 500 KB bought 73.7% more pixels for 66.8% more bytes, but only 15.3% less average error at a 1600 × 2400 frame. What did improve sharply is the tail: samples off by more than 16 levels fell from 1.67% to 0.79%. So 500 KB is meaningfully better on hard edges and fine texture, and close to identical on smooth areas.

Why does my 300 KB output say 299 KB?

Because the encoder stops as soon as it is under the target rather than filling it exactly, and the display rounds. 306,526 bytes is 299.3 KB at 1,024 bytes per kilobyte, and it is 674 bytes under the 307,200-byte ceiling. Nothing is wrong; the file simply has a little unused room.

Can I get 4000 × 6000 pixels into 300 KB?

Not as a photograph. At 24 megapixels and quality 40.5%, 300 KB would need 0.0128 bytes per pixel, and the measured cost at this budget is 0.0634 — five times more. The compressor scales to 45% of the original dimensions instead. If the dimensions are non-negotiable, the budget has to rise to roughly 1.2 MB, which is where the same file stops being cut at all.

Does a PNG photograph reach 300 KB?

Only by collapsing. An 18.97 MB 4000 × 6000 PNG at this target came back at 319 × 478 — 152,482 pixels, 294,795 bytes, scaled to 8%. PNG is lossless, so its only lever is area. Convert to JPG first if the dimensions matter.

Is 300 KB enough for printing?

4.84 megapixels prints 9.0 × 13.5 inches at 200 dpi, or 6.0 × 9.0 inches at 300 dpi. For a 6 × 4 inch print it is comfortable; for A4 at 300 dpi it is not, and no amount of re-encoding fixes that — the pixels are not there. If print is the destination, the budget needs to be in the megabyte range, which is what the 2 MB study covers.

Does the image get uploaded when you compress it to 300 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 returns the same bytes.

Every number here comes from one photograph pushed through nine budgets. 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.

At the tight end of the same family, why a JPEG gives up pixels before it gives up quality, and the 8 × 8 block grid that decides which pictures keep them, is on the JPEG 20 KB page.

Two tiers up, at 1 MB the same photograph stops being cut at all — 19.75 megapixels kept whole — and the budget switches from buying area to buying quality. That measurement is on the 1 MB page.

If the reason you are here is an error message rather than a number you chose, that is a different problem: "image too large to upload" covers four separate limits, and a 300 KB file can still be refused on dimensions. The one-minute test that separates them is on the upload error page.