"Image too large to upload" — the two numbers that decide which fix you need

That message covers four different failures, and only one of them is about size in megabytes. The two numbers to read off your file are its byte count and its pixel width. If the bytes are over the limit, compress. If the bytes are under and it still fails, the limit is pixels or format — and no amount of compressing will move it.

Here is the measurement that makes the distinction concrete. A 54-megapixel photograph (6000 × 9000, 11,525,365 bytes) pushed to a 2 MB target came back at 5755 × 8633 — 49.68 megapixels, only 8% fewer pixels than the original. The bytes fell by 82%. The dimensions barely moved. If the form caps width at 2000 pixels, that file is rejected at 2 MB, at 1 MB and at 500 KB alike, and it will keep being rejected until you resize it.

Test conditions: Chrome 155 on Windows 11, this site's compressor driven through its published interface. Source files: a 6000 × 9000 JPEG of 11,525,365 bytes; a 4000 × 4000 PNG of 84,394 bytes; a 1000 × 1500 JPEG of 417,234 bytes. One encode per row, one sample per file — not a distribution. Dimensions, bytes and quality are what the result panel reported; nothing here is extrapolated from a formula.

Why the message is vague instead of telling you the actual limit

Because the browser often cannot render the real error. nginx, the web server in front of a large share of the internet, documents this in its own manual for the setting that produces the failure:

PHP has the same shape of default, one layer further in. The php.net manual lists upload_max_filesize with a default of "2M", and post_max_size beside it. Both were read on 25 October 2026. Neither number is a decision anyone made about your photo — they are what you get when nobody changes anything.

That is why a 3 MB phone photo fails on a site whose form says nothing about a limit, and why the message reads like a generic complaint instead of "your file is 3,492,678 bytes and the ceiling is 1,048,576". The two defaults explain a large share of the reports behind this search term. They do not explain all of them, and that is the point of the next table.

A 54-megapixel photo clears a 10 MB limit and can still be rejected

One file, six targets, from the largest limit people usually meet down to the one this site's other pages spend their time on. The last two columns are the ones that matter for this error: the pixel width the output ends up at, and how much of the original area survived.

Three things fall out of this table, and each one maps to a different fix.

First: the top of the range is not a size limit at all. Asking for 10,240 KB and asking for 9,766 KB produced the same 9,841,886 bytes at the same 95.31% quality. The encoder ran out of quality to spend before it ran out of budget — at 95.31% it stopped, and there is nothing above that worth doing. So if a form has a 10 MB limit and rejects this file, the file is not too big in bytes: 9,841,886 is under both 10,000,000 and 10,485,760. Something else is rejecting it, and the thing that is 6000 pixels wide is the obvious suspect.

Second: from 10 MB down to 5 MB, the dimensions do not move by one pixel. The whole 4.8 MB of savings came out of quality, from 95.31% to 82.19%. That is the regime where compressing is a clean win: same picture dimensions, fewer bytes, no visible cost. It is also the regime where the error message, if it appears, is genuinely about bytes.

Third: the frame only starts collapsing below about 2 MB. At 2,048 KB the file is still 5755 pixels wide. It takes a 1,024 KB target to reach 3606 pixels, and 500 KB to reach 2360. So the answer to "how many bytes do I need to get under 4000 pixels wide" is roughly one megabyte — and that is a much bigger cut than most people expect when the form only says "max 2 MB".

The 16-megapixel image that weighs 84 KB

Now the case where every byte-based check passes and the upload still fails. A flat artwork PNG, 4000 × 4000, is 84,394 bytes. It would clear a 1 MB limit, a 2 MB limit and a 10 MB limit without being touched. It is also 16 megapixels, and a form that caps width at 2000 pixels will reject it every time.

Compressing it does not help, and it can actively hurt. Pushed through with a 10 MB target and JPG selected as the output, it came back at 565,928 bytes — 6.71 times larger than the file that went in, at quality 99.53%. Nothing malfunctioned: the tool was told to produce a JPG near 10 MB, it kept all 16 megapixels, and it raised quality until it ran out of room to raise it further. The file was never too large. It was asked to become larger.

This is the failure mode worth remembering, because it produces the same error message as everything else on this page while being the exact opposite problem: a file that fails a pixel check, gets "compressed" to satisfy a byte check it already satisfied, and comes back both bigger and still the wrong shape. The fix is a resize, and if you want the mechanics of that at the tight end, the folder run page measures what happens when ten files are pushed through a single limit.

The four limits, and the one test that separates them

The one test worth doing first is the second row's: compress the same picture to about 200 KB and try again. It costs one minute and it splits the problem in half. If the 200 KB version uploads, the limit was bytes and you are done — you can walk the budget back up until it fails if you want the largest file that passes. If the 200 KB version also fails, the limit is dimensions or format, and every further attempt at compressing is wasted effort.

What 200 KB actually holds for a photograph is 1447 × 2170 in our measurements — the full ladder is on the 200 KB page. If the form's pixel cap is above 2170, a 200 KB test tells you the truth. If the cap is below it, the test can fail for a reason that has nothing to do with the byte limit, which is itself the answer.

If the form says 10 MB, type 9,765

"10 MB" has two meanings in the wild, and the difference is 485,760 bytes. A decimal limit is 10,000,000 bytes. A binary limit is 10 × 1024 × 1024 = 10,485,760. This compressor counts 1,024 bytes to a kilobyte, so a 10,240 KB target means 10,485,760 bytes — the binary reading, and 485,760 bytes over the decimal one.

On the test file it made no difference, because the encoder stopped at 9,841,886 either way — and note that 9,766 KB is itself 10,000,384 bytes, 384 over a decimal 10 MB. That is luck, not a rule. On a file that can actually fill the budget, those 384 bytes decide whether the upload passes. 9,765 KB is the largest whole kilobyte below 10,000,000 (9,999,360 bytes), and the measured run at 9,766 KB returned 9,841,886 — 158,114 bytes under the decimal limit, and under the binary one too. The same logic at other common limits: for a stated 5 MB, use 4,882 KB; for a stated 2 MB, use 1,953 KB — that one is measured on the 2 MB page.

What to do, in order

1. Read the unit, not the number. "Max 5 MB" and "max 5 MP" are different rules. One is answered by compressing, the other only by resizing.
2. Run the 200 KB test. If the small copy uploads, the limit was bytes. If it does not, stop compressing and go to step four.
3. Set the target under the stated limit, in this tool's units. 9,765 KB for a 10 MB form, 4,882 KB for 5 MB, 1,953 KB for 2 MB, 293 KB for 300 KB. Each of those is below both the decimal and the binary reading of the same label.
4. If it is a pixel limit, cut the dimensions instead. A 6000 × 9000 file needs about a 1 MB target to reach 3606 pixels wide, and a 500 KB target to reach 2360. Resizing directly is more predictable than letting a byte budget decide for you.
5. If it is a format limit, re-encode rather than rename. A .png renamed to .jpg is still a PNG, and a whitelist that reads the file's actual type will still refuse it.
6. If the file already passes, send it untouched. A 417,234-byte JPEG at a 10 MB target came back at 417,234 bytes, byte for byte — the compressor recognised it was already inside the limit and did nothing. The same file converted to another format at a 10 MB target grew 6.71×. The safe move is to change nothing.

Why the file has to be handled locally for this to work

There is an awkward recursion in this problem: the tool that fixes your oversized file is often an upload form itself, with a limit of its own. A 54-megapixel, 11.5 MB source is exactly the kind of file that gets rejected by an online compressor before it gets a chance to make it smaller.

On this site the file never leaves the machine. It 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, so the 11,525,365-byte source above went in and a 9,841,886-byte output came out without a single byte crossing the network. That is not a privacy slogan here, it is the reason the largest test file on this page could be tested at all.

Questions this page gets

Why does it say "image too large to upload" when my file is only 3 MB?

Because 3 MB is over both common defaults. nginx rejects request bodies above 1 MB out of the box and returns 413; PHP caps upload_max_filesize at 2M out of the box. A 3.3 MB photo fails either. Neither number was chosen by the person running the site, which is why the form often does not mention a limit at all.

I compressed to 2 MB and it still will not upload. What now?

Check the width of the output before you try again. The 6000 × 9000 test file at a 2 MB target came back at 5755 × 8633 — the byte check passes and the pixel check does not. If the form has a pixel cap, you need to go down to about 1 MB to reach 3606 pixels, or resize deliberately and skip the guessing.

Does resizing lose more than compressing?

It depends on which limit you are fighting. Against a byte limit, compressing is strictly better, because it keeps the dimensions and spends quality. Against a pixel limit, resizing is the only thing that works, and the question becomes how far to go rather than whether to. Our measurements of what survives at each budget are on the 500 KB page and the 300 KB page.

Can compressing make a file too large to upload?

Yes. An 84,394-byte PNG converted to JPG at a 10 MB target returned 565,928 bytes — 6.71× the source, at quality 99.53%. If your file already passes the check, compressing it is not a no-op, it is a re-encode with a budget to fill.

Is 10 MB the same as 10,485,760 bytes?

Not always. Decimal gives 10,000,000; binary gives 10,485,760. This tool uses the binary reading, so 10,240 KB is 10,485,760 bytes. Enter 9,765 KB if you want to clear both readings on the same form.

What if the file is a phone photo in HEIC?

Then size may not be the problem at all, and this page cannot tell you what is, because we have not measured HEIC handling on this site. What we can say is that a format whitelist is the fourth limit in the table above, and the test for it is the same: save the same picture as JPG and try again. If the JPG uploads, the limit was the format.

If the limit turns out to be bytes after all, the question becomes how many pixels your budget holds. For a photograph that is 4.84 megapixels at 300 KB, 8.41 at 500 KB and 19.75 at 1 MB — each measured the same way, on the 300 KB page.

And if the number in the form came from an official specification rather than a web developer's default, the three sets of rules we read line by line — UK, New Zealand and Canada — are on the portal requirements page, with the source URLs and the date each was read.