"Image size too large": an 84 KB file that is 16 megapixels

An 84,394-byte PNG measuring 4000 × 4000 pixels is an ordinary file — a flat graphic, a logo lockup, a slide export. Every form that counts bytes takes it without complaint. The same file becomes 64,000,000 bytes once it is decoded into pixels, 758 times its size on disk, and a site that counts megapixels refuses it while happily accepting a 3.49 MB photograph that needs only 1.5 times as much memory.

Across twelve real files measured today, the factor between bytes on disk and bytes of pixels runs from 6.05× to 835× — a 138-fold spread. So "image size" is two numbers, and the message never says which one it means. One multiplication settles it: if the site says megapixels or a pixel width, it is counting width × height; if it says MB, it is counting the file.

Test conditions: Chrome 155 on Windows 11, this site's compressor served locally on 127.0.0.1, one file at a time through the normal file input. Twelve files inspected, nine compression runs. Byte counts come from fs.statSync on the file on disk, and for outputs from the page's own report object. Pixel dimensions are the decoded ImageBitmap.width and ImageBitmap.height after createImageBitmap() on the same File object the tool decodes — the numbers the browser actually loaded, not the ones in the filename. "Decoded bytes" is pixels × 4, the size of an 8-bit RGBA buffer, and is arithmetic. Decode times are three createImageBitmap() calls per file on the same machine, listed raw.

Twelve files, one table, and a factor that runs 6× to 835×

Each row is one file: its byte count on disk, the pixels the browser decoded out of it, and what those pixels cost once they are a buffer in memory.

Look at rows eight and nine. Both are 24.00 megapixels and both decode to exactly 96,000,000 bytes — the JPEG at 3,492,678 bytes and the PNG scan at 1,297,068. Identical cost to the server, and 2.69× apart in the number a person reads in a file manager. A byte counter sees two very different files; a pixel counter sees the same file twice.

And the extremes are 138× apart. The 84,394-byte graphic and the 11,525,365-byte photograph differ by a factor of 136.6 on disk, but only 3.4 in the memory they occupy. If you picked the "smaller" file to send, you picked the one that costs the server more than a third as much as the "huge" one, at 1/137th of the bytes.

Why a flat graphic expands 758× and a photograph only 27×

A JPEG spends its bytes on local detail: after the block transform, a region of near-uniform colour produces almost no coefficients, so a 16-million-pixel flat fill can be described by a few hundred bytes of repetition. A photograph at the same resolution has detail in every block, and the encoder has to pay for all of it. That is the entire difference between 758× and 27×, and it is a property of the picture, not of the file type.

PNG tells the same story with a different compressor. Rows of identical or near-identical bytes deflate to almost nothing, which is why the cut-out (835×) and the flat graphic (758×) are the top two rows, and why the document scan — mostly white paper with thin dark strokes — expands 74× rather than 27×.

The gradient is the other end of the scale and the most instructive row in the table: 2,537,877 bytes for 3,840,000 pixels, an expansion of only 6.05×, because every pixel differs slightly from its neighbour and there is nothing to repeat. It is the one file here whose byte count is within an order of magnitude of its pixel count. A photographic gradient is also the case where a byte limit bites first and a pixel limit almost never does.

The practical consequence is uncomfortable: the byte count tells you how much detail is in the picture, and the pixel count tells you how much work the server has to do. They are independent measurements of the same file, and "image size too large" is ambiguous between them. That ambiguity is why the same file gets rejected by one site and accepted by another with a bigger limit in the other unit.

A byte target only removes pixels it has to

This is the mechanism behind "I compressed it and it is still rejected". The tool treats the target as a ceiling and checks it first: if the file is already at or under the target and already in the requested output format, it hands the original back untouched. Two measured runs, both on files that were already small:

When the target is below the file, the encoder searches in a fixed order: keep the dimensions and drop quality, but only to a 40% floor, then start scaling. So the pixel count only falls after the byte budget has been spent on quality, which is why the photograph at a 2000 KB target kept all 24.00 MP at 70% quality and the same photograph at 1000 KB fell to 19.19 MP at 40%.

The third row is the trap. If your ceiling is 12 MP, 3464 × 3464 would have passed with 12.00 MP. Instead the file was pushed to 1016 × 1016 to satisfy a 50 KB number nobody asked for — 1.03 MP, 6.45% of the pixels, and a picture that is no longer usable at any size. Compressing to fix a pixel problem costs pixels in proportion to how far below the file's own size you push the byte target, not in proportion to how far over the ceiling you were.

If the ceiling is megapixels, this is the byte target that reaches it

Same 24-megapixel photograph, five targets, all measured today. The output pixel count is the number that decides whether a megapixel ceiling accepts the file.

The mapping from bytes to megapixels is monotone but nowhere near proportional. Halving the target from 1000 KB to 500 KB costs 56.2% of the pixels (19.19 → 8.41), and dropping from 500 KB to 300 KB costs another 42.5% (8.41 → 4.84). Going up, the first 1000 KB buys 19.19 MP and the second 1000 KB buys only 4.81 MP more, because the encoder is trading quality as well as pixels.

For a 12 MP ceiling the answer is therefore 500 KB: 8.41 MP passes, 19.19 MP at 1000 KB does not. For an 8 MP ceiling, 500 KB is also the answer. For a 20 MP ceiling, 1000 KB is 19.19 MP and squeaks through. Those are measured points, not a formula — the curve moves with the picture.

The last three rows show why a single target number cannot be a rule. 300 KB is a no-op on the flat graphic (16.00 MP out, 84,394 bytes, 0 ms) and catastrophic on the document scan (0.42 MP out). Same target, same day, same encoder: 38× apart in output pixels, decided entirely by how many bytes the source picture already needed per pixel.

A 25% cut in pixels is a 13.4% cut per edge

Pixel count is area, so it moves with the square of the edge. That single fact is where most resize arithmetic goes wrong, and it is the cheapest lever available when the ceiling is megapixels.

For the 16 MP graphic, the edge factor to reach 12 MP is 0.8660 — a 13.4% trim on each side, which most pictures survive without anyone noticing. That is a far cheaper fix than the 50 KB byte target that took the same file to 1.03 MP. When the ceiling is expressed in pixels, the fix is a trim; when it is expressed in bytes, the fix is a re-encode. On this file the wrong fix threw away 11.6× more pixels than the 12 MP ceiling required — 1.03 MP delivered where 12.00 MP would have passed.

The ceiling that is never published: 128 MB of memory

Many servers reject an image without ever stating a pixel limit, because their limit is not a rule about pictures — it is a rule about memory. The PHP manual lists memory_limit with a default of "128M" and describes it as "the maximum amount of memory in bytes that a script is allowed to allocate" (php.net, ini.core.php, read 28 October 2026). A decoded image is the largest thing that script will allocate.

At four bytes per pixel, the files in the first table map onto that limit directly. The 84,394-byte graphic needs 64,000,000 bytes (61.0 MB). The 1,297,068-byte scan needs 96,000,000 bytes (91.6 MB). The 11,525,365-byte photograph needs 216,000,000 bytes (206.0 MB), which is already past 134,217,728 — the byte value of 128M — before the encoder allocates a second buffer for its own output.

Two honest caveats. The buffer size is arithmetic from the pixel count, not a measurement of any particular server's allocation; real decoders may hold one buffer or three. And whether a given site reports this as "image size too large", as a 500 error, or as a silent failure is up to the site — the 128M default is documented, the diagnosis that a specific rejection came from it is an inference.

What is not an inference is the ordering. A 4000 × 4000 PNG of a flat logo and a 4000 × 6000 JPEG of a landscape are 84 KB and 3.49 MB on disk and 61.0 MB and 91.6 MB in memory. Any limit expressed in the first pair of numbers ranks them one way; any limit expressed in the second pair ranks them the other way. That is the whole of this page in one sentence, and it is why the fix has to be chosen from the unit in the message.

Questions this page gets

Why does a site reject my 84 KB image when it accepts 3 MB photos?

Because it is counting pixels. 84,394 bytes at 4000 × 4000 is 16.00 MP and needs 64,000,000 bytes decoded; a 3,492,678-byte photograph at 4000 × 6000 is 24.00 MP and needs 96,000,000. The small file is 41 times smaller on disk and only 1.5 times smaller in the unit the server spends. If the site's message mentions pixels, width, height or megapixels, that is the number it is comparing.

How do I find the megapixel count?

Width × height ÷ 1,000,000. 4000 × 4000 = 16.0 MP. On Windows, right-click the file, Properties, Details tab, and read the Dimensions line; macOS shows it in Get Info under More Info. Or drop the file on the tool at the top of this site: it prints 82 KB · 4000 × 4000 px as soon as the file is loaded, before any compression and without sending it anywhere.

I compressed it and it is still rejected. Why?

Two measured reasons. First, if the file was already under the byte target, the output is the input: 84,394 bytes in, 84,394 bytes out, 0 ms, dimensions untouched. Second, even when the target does bite, the encoder spends the budget on quality before pixels, so a 24 MP photograph at 2000 KB came back at 24.00 MP and 70.5% quality. In both cases the pixel count — the number the site may be rejecting — did not move.

Which byte target gets a 24 MP photo under a 12 MP ceiling?

500 KB, measured: 2367 × 3551 = 8.41 MP. 1000 KB is not enough — it returns 3577 × 5365 = 19.19 MP, which is still over 12 MP. The full measured ladder from 2000 KB down to 200 KB is in the table above, and the per-target pixel budgets for individual sizes are written up on 300 KB and 500 KB.

Is resizing to 75% a 25% cut in pixels?

No. 0.75 on each edge keeps 0.5625 of the area, which is a 43.75% cut. To remove 25% of the pixels you need 0.8660 on each edge. This is the single most common arithmetic error in resize instructions, and it runs in the direction that hurts: people think they have cut a quarter and have cut nearly half.

Does the same thing happen with PNG?

Worse, because PNG is lossless and has no quality dial — pixels are the only lever. The 4000 × 6000 PNG scan at a 300 KB target came back at 527 × 790, which is 0.42 MP, 1.73% of the original. The flat 4000 × 4000 PNG at the same 300 KB target was passed through at 16.00 MP because it was only 84,394 bytes to begin with. Same target, 38× difference in output pixels.

If the number in your error is bytes and you have already checked the units, the measured pixel budget for each byte target is on 300 KB (4.84 MP), 500 KB (8.41 MP) and 1 MB (19.75 MP kept whole). Each page states the byte value to type for a strict decimal limit as well.

If you do not yet know which kind of limit you are hitting, the triage page separates the four that produce this message, and if the bytes are being inflated between your disk and the server, that measurement is here — base64 turns a file into 4/3 of itself. The unit question, KB against MB, is on the 1953 KB page.

The boundary this page can defend, measured: at a 300 KB target the encoder will not hand back more than 4.84 megapixels from a 24-megapixel photograph, and at the same 300 KB target it will hand back all 16.00 megapixels of a flat graphic untouched, because that graphic was already 84,394 bytes. Same target, same day, 38× apart in output pixels — and the only way to know which side of that you are on is to read the two numbers before you press the button.