Why does a PNG to ICO converter reject my file?

Test date: November 2, 2026

This converter stops before export if a PNG exceeds 10,485,760 bytes, either header dimension exceeds 8,192 pixels, or its header dimensions multiply to more than 16,000,000 pixels. In a controlled run, files at each tested boundary passed; the next tested step failed.

This was a local Chrome run of the current SVGTOPIX converter source. It tests that implementation, not every PNG-to-ICO service. I tested the SVGTOPIX build directly instead of trusting another service's landing page because I have already wasted far too much time hunting for a PNG-to-ICO tool that is actually good and easy to use. Rather than guess from a competitor's vague "fast and free" copy, I ran the current source locally to learn its real, enforced limits in one sitting — so I, and you if you are in the same boat, stop burning hours on tools that quietly reject the files we actually have.

What the boundary run returned

The byte check and the PNG header checks are separate. The 10 MiB fixture was only 1 × 1 pixel; the pixel-area fixture was under 70 KB. A small compressed file can still declare a large image. Which check will it hit? File size alone cannot tell you. Picture a ZIP file: it can sit at a few kilobytes on disk yet unpack into gigabytes. A PNG is the same idea. The file size is just how many bytes the compressed package takes up; the header quietly says "this package, once opened, is 4,000 by 4,000 pixels." A 70 KB file can be telling the truth about a 16-megapixel image. So when the converter rejects you, the file's weight on disk is the last thing that will explain why — the header's claimed size is what actually trips the wire.

Input bytes and the exact interface messages came from the seven generated files and the browser run. Successful ICO byte totals were read from the downloaded files. "None" means the interface exposed no download and no output ICO was written. Lining the rows up is genuinely satisfying. One byte more and "Accepted; 7 frames" becomes "Rejected". One pixel more on one side and the whole thing fails. The clearest pair is the 10,485,760 vs 10,485,761 byte files — identical 1×1 pictures, nothing visually different at all, yet one downloads and the other is blocked. It turns an abstract "limits" section into something you can see, and it makes the boundaries feel real rather than like fine print nobody reads.

Which check failed?

The file-size message points to the byte count: compare it with 10,485,760. The fixture at that size downloaded; the one one byte larger did not. The dimension message points to the PNG header. A side above 8,192 fails even when the other side is 1 pixel. For the pixel-area check, multiply width by height: 4,000 × 4,000 passed at 16,000,000 pixels; 4,001 × 4,000 failed at 16,004,000. That is why the rejection message matters more than the compressed PNG size alone. When a file gets rejected, read the error message before doing anything else — it names the exact check that fired. If it says "10 MB", the byte cap is the problem. The 10 MiB fixture shows one way a file can reach that boundary: its CRC-valid ancillary text chunk brings it to exactly 10,485,760 bytes. If it says "8192" or "16 million pixels", the dimensions are the problem and no amount of compression will save you — you have to resize the image smaller. Most people's first instinct is to compress; that only helps if the byte limit was the real blocker, so check the message first and you'll avoid wasted effort.

Read back the actual ICO files

I parsed the downloaded ICO directory entries and checked each payload's PNG signature and IHDR dimensions. Each successful output contained seven entries. The directory dimensions matched the embedded PNG dimensions at 16, 24, 32, 48, 64, 128, and 256 pixels. The 1 × 1 control and exact-byte-limit outputs were 4,276 bytes; the 8,192 × 1 output was 4,222 bytes. The rejected files had no ICO to decode.

The evidence bundle includes the seven source PNGs, the four actual ICO downloads, the raw browser observations, the directory read-back, and the scripts. The synthetic 10 MiB PNG uses a CRC-valid ancillary text chunk to reach the exact byte boundary; it is a boundary fixture, not a typical photo.

Download and reproduce

1. Download and extract the input-limit evidence bundle.
2. Upload one fixture at a time to the PNG to ICO converter. Compare the exact visible result with results/ui-observations.json.
3. For an accepted file, run node decode-ico-directory.mjs downloads/control-1x1.ico from the extracted bundle folder to read its directory entries and embedded PNG dimensions. The script uses only Node’s built-in modules.

The boundary numbers describe this tested SVGTOPIX build and these generated PNG fixtures. They do not establish the limits of other converters or every malformed PNG.

Pages checked

CloudConvert PNG to ICO. The page describes controls for resolution, quality, and file size. It does not state a numeric PNG input boundary on the page read for this review. FreeConvert PNG to ICO states a maximum file size of 1 GB. Convertio PNG to ICO presents its PNG-to-ICO flow. These pages were read on November 2, 2026. This article reports a separate test of the SVGTOPIX implementation. It does not compare the services by running the same fixtures through them.