Compress an image to 2 MB — where nothing gets cut, and the budget starts buying quality

Set the target to 2,048 KB and you are done. A 3.33 MB 4000 × 6000 JPEG came back at 4000 × 6000, 2,057,030 bytes, quality 72.3% in 4.6 seconds — every one of the 24 million pixels still there. If the form on the other side means two million bytes rather than two mebibytes, set 1,953 KB instead: 1,953 × 1,024 = 1,999,872 bytes, under the limit by construction.

That result is the point of this page. At 500 KB the same file lost two thirds of its pixels and at 1 MB it lost a fifth. At 2 MB it loses none, and the entire byte budget goes somewhere else: quality. Which means the mistakes available to you at this budget are different mistakes — not a soft picture, but a file that came back bigger than the one you fed in.

Test conditions: Chrome 155 on Windows 11, this site's compressor, driven through its published interface on 24 October 2026. Source photograph: a 4000 × 6000 JPEG, 3,492,678 bytes. Each row is one encode of one file — a sample, not a distribution. Bytes per pixel and every ratio below use output bytes over output pixels, the same sample point on both sides. Where a figure is arithmetic rather than measurement I say so. The quality percentages are what the tool itself reported.

Who is actually enforcing 2 MB

Before the numbers, the reason this budget exists at all. PHP ships with upload_max_filesize set to 2M and post_max_size set to 8M in its default configuration — that is the documented default, read from the PHP manual on 24 October 2026, not something I inferred. A form running on a stock PHP install therefore rejects anything over two megabytes, and the rejection arrives before the application code ever sees the file.

My inference, and I will label it as one: a good share of the "2 MB" ceilings you meet on small business sites, club membership forms and university portals are not product decisions at all. They are that default showing through. I cannot verify any particular site's reason from the outside, and a limit can equally be a deliberate choice or a hosting plan's cap. What I can say is that the number repeats too often, in too many unrelated places, to be a coincidence of taste.

The other thing worth knowing is that "2 MB" is two different numbers depending on who is counting. This tool treats a kilobyte as 1,024 bytes, so 2 MB is 2,097,152. A form that counts 1,000 bytes to the kilobyte means 2,000,000. The gap between those two readings is 97,152 bytes — nearly a tenth of the budget — and it is enough to fail a form that looked satisfied.

At 2 MB the budget stops buying pixels

One photograph, eight budgets from 1,200 KB upward. Watch which column moves:

Eight runs, one source file (3,492,678 bytes), JPG output. "Untouched" means the target was above the source size and the file was already a JPG, so the tool returned the original bytes without re-encoding.

The dimensions column is flat from 1,500 KB upward, and it is flat because the frame already fits — at 1,200 KB the encoder still trimmed it to 3993 × 5989, a rounding artifact of its scale search rather than a real reduction. So everything a 2 MB budget can do, it does to the quality column: 40.5% at 1,200 KB, 72.3% at 2 MB, 80.3% at 3 MB.

The marginal return, though, is not even. Going from 1,500 KB to 2,048 KB costs 548 KB and buys 20.1 quality points. Going from 2,500 KB to 3,000 KB costs 500 KB and buys 2.8. The curve bends somewhere above two megabytes, which is the practical argument for stopping here: below roughly 2.5 MB every extra hundred kilobytes still visibly buys something, and above it you are paying for a difference the eye will not collect.

2 MB against 1 MB, pixel by pixel

"Is the bigger one actually better" is a question people answer by squinting. It can be measured. I took a six-megapixel photograph saved at quality 100 (3,599,809 bytes), compressed it twice — once at 1,024 KB, once at 2,048 KB — and both outputs came back at exactly 2000 × 3000, so the comparison is quality against quality on one grid with no resampling in between. Then I decoded both and compared every channel of every pixel.

Two comparisons, decoded with createImageBitmap and read back through canvas. "Mean difference" is the average absolute difference across the red, green and blue channels, on a scale where 255 is the largest possible. Percentages count pixels where any one channel moved by more than eight levels.

Read the second row first, because it is the more surprising one. A twelve-megapixel photograph at a 2 MB target was already inside the limit at 2,062,391 bytes, so the tool did nothing — and that untouched original differs from its 1 MB version by an average of 2.3 levels per channel. Fewer than one pixel in two hundred moved by more than sixteen levels. That is what "you cannot see the difference" looks like when you write it down.

The first row is the controlled version: both files re-encoded, same dimensions, quality 83.1% against 97.2%. Fourteen quality points and 955,256 extra bytes produced an average change of 2.14 levels — under one percent of the available range — and no pixel anywhere in six million moved by more than 36 levels.

Where the difference does live is in texture. Splitting each frame into 32 × 32 blocks and averaging the per-pixel difference inside each block, the median block moved 2.59 levels but the ninetieth-percentile block moved 6.12 — two and a half times as much — and the worst block in the frame moved 8.55. Fine detail is where the bytes went. Flat sky, skin, walls: effectively identical. Hair, foliage, fabric weave: measurably different, and visible if you zoom to 100% and know what you are looking for.

One honest limit on all of this: mean absolute difference is arithmetic, not a perceptual model. It says how far the numbers moved, not whether a person notices. I did not compute a structural similarity score, so I am not going to dress these figures up as a visibility threshold. What they establish is scale — a two-fold budget difference at identical dimensions moves the average pixel by about one percent of the range.

What 2 MB does to a scan, a text page, flat art, a cutout and a gradient

This is where the tier turns against you. Six files, one 2 MB target, all JPG out:

Six runs, one 2 MB target (2,097,152 bytes). Every source except the photograph was a PNG going in and a JPG coming out. "Output ÷ source" is output bytes divided by source bytes; above one means the file grew.

Four of the six came back larger than they went in. Not because the compressor failed — it stayed under the limit every time — but because JPEG has to spend bytes describing flat colour that PNG stored almost free, and at this budget there is room to do it. Flat artwork went from 84,394 bytes to 565,928. A cutout on white went from 62,081 to 324,148. A scanned page went from 1,297,068 to 2,094,985.

The scan is the interesting one, because it grew and landed at the lowest quality of the six: 44.2%. Dense print is the worst case for JPEG at any budget — every letter edge is high-frequency detail — and at 2 MB there is enough room to keep all 24 million pixels, so the encoder spends everything it has on describing them and still only reaches 44.2%. A scan at this budget is a file that got bigger and noisier at the same time.

The photograph is the only row that behaves like a compression: 3,492,678 bytes in, 2,057,030 out, all pixels kept. If you are compressing to get under a limit and the file is a photograph, this budget is generous enough to be almost free. If it is flat art or a cutout, the correct move is to leave the PNG alone — it was already smaller than anything JPEG can offer.

WebP at 2 MB buys quality, not area

At 500 KB, WebP's advantage shows up as pixels — the same photograph got 15.34 megapixels instead of 8.41. At 2 MB the pixels are already safe, so the advantage moves to the quality number:

Three runs, one 2 MB target, one 4000 × 6000 source. PNG has no quality dial in this tool, so its only variable is pixel count.

Thirteen quality points for the same bytes, at seven times the encode time. Whether that trade is worth it depends entirely on where the file is going: a browser will take WebP, a print shop will not, and a form that validates MIME types will reject it before anyone looks at the picture. Thirty-two seconds is also long enough that people abandon the tab — that is a real cost, not a footnote.

PNG remains the wrong tool for photographs at any budget. Even with two megabytes to spend, the lossless path can only reach 861 × 1291 — 1,111,251 pixels, under five percent of the frame. Its 1.87 bytes per pixel is more than twenty times JPEG's 0.086 at this budget.

2 MB is 2,097,152 bytes, and 1,953 KB is the safe setting

The photograph's 2 MB output landed at 2,057,030 bytes — 98.1% of the 2,097,152-byte budget, which is the tool doing its job precisely. Against a form that means 2,000,000 bytes, that file is 57,030 bytes over.

The fix is arithmetic, not measurement: 1,953 × 1,024 = 1,999,872 bytes, which clears a two-million-byte limit with 128 bytes to spare. 1,954 KB would be 2,000,896 and would not. So the safe target for a strict decimal limit is 1,953 KB, and the cost is small — you give up about 97 KB of budget, which by the ladder above is roughly one quality point.

Two megabytes of headroom is also where the "did it work at all" question starts to bite. A file at 2,062,391 bytes compressed to a 2 MB target returns unchanged in 0 ms, with no quality value, because it was already inside the limit and already a JPG. The tool will not re-encode a file that does not need it, and it will not spend your quality to hit a target you already met. If the button seems to do nothing, check the size first.

How to compress an image to 2 MB, step by step

1. Look at the size first. Under 2,097,152 bytes and already a JPG? The tool returns it untouched and there is nothing to gain by forcing a re-encode.
2. Pick the right number. 2,048 KB for a binary limit, 1,953 KB for a form that means two million bytes. The difference is 97,152 bytes of budget and the difference between passing and failing.
3. Drop the file and press compress. JPG, PNG, WebP, GIF and BMP all load; the result panel reports output dimensions, output bytes and quality.
4. Read the quality, not the dimensions. At this budget the dimensions will usually be untouched. A quality of 99.5% means the encoder had budget left over; 72% means it used what it had.
5. Do not convert a small PNG. If the source was a PNG already under the limit, converting it to JPG at 2 MB can triple or sextuple its size for no visible gain.
6. Choose WebP only if the destination accepts it. It buys quality at this budget, not area, and it costs seven times the encode time.

Questions people ask about 2 MB images

How do I compress a photo to under 2 MB?

Set 2,048 KB and compress. A 3.33 MB 4000 × 6000 JPEG came back at 2,057,030 bytes with all 24 million pixels and quality 72.3%, in 4.6 seconds. If your form counts a megabyte as a million bytes, use 1,953 KB and land at 1,999,872.

Will 2 MB keep my full resolution?

For anything up to 24 megapixels of ordinary photograph, yes. The frame stopped being trimmed somewhere between 1,200 KB and 1,500 KB on my test file, so by the time you reach 2 MB the budget is entirely quality. A file that keeps getting cropped at 2 MB is one with far more detail than a photograph carries.

Why did the 2 MB version come out bigger than my original?

Because you converted a PNG. Flat artwork at 84,394 bytes became 565,928, a cutout at 62,081 became 324,148, and a scanned page at 1,297,068 became 2,094,985 — all under the limit, all larger than the source. If the source is already small and already the right format, leave it.

Is 2 MB enough for printing?

At 4000 × 6000, a 300 dpi print is 13.3 × 20 inches, and quality 72.3% is high enough that the compression is not the limiting factor — the paper size you can afford is. That is a different situation from 500 KB, where the file is at the 40.5% floor and fine texture is already gone.

Should I use 2 MB or 1 MB?

If the form allows 2 MB, use it: the pixels are free at this tier and the quality is 72.3% against 40.5%. If it allows only 1 MB, you are still fine for anything under about 19.75 megapixels, but the file sits at the quality floor — which is what the 1 MB page measures in detail.

The budget below this one behaves completely differently — at 500 KB the dimensions are cut and the quality is pinned at the floor, which is measured on the 500 KB page.

The budget above it, where a 24-megapixel frame keeps every pixel at 48% instead of 72%, is on the 1 MB page.

If your file is a PNG that needs converting rather than compressing, what the conversion itself throws away is measured on the convert to JPG page.

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

Above this tier the budget stops being a constraint at all: at 5 MB nothing gets cut, small PNGs get inflated to fill the budget, and the failures that remain are dimension and decimal rules rather than bytes — measured on the 5 MB page.