PNG to ICO Converter: Why These Test Files Differ by About 20×

Four downloaded files, one source image

The same local PNG was uploaded to each site. The default selections yielded four entries at CanDoYa and thecalcu, six at ConvertICO.com, and nine at PNGtoICO.com. CanDoYa and thecalcu's two downloads had the same SHA-256 hash and were identical byte for byte in this run. That establishes equality of these two files for this input and these settings; it does not establish that the sites share code, a backend, or an owner.

The 18,209-byte pair contains PNG-encoded frames with DEFLATE-compressed image data. The other two files contain 32-bit DIB bitmap frames marked BI_RGB (compression value 0). The term 'uncompressed' here describes those stored DIB pixel frames; the total ICO still has its directory and frame headers.

Measured file lengths and frame data

The frame-data lengths below are the complete data blocks referenced by each ICO directory entry. For the PNG-encoded frames, the PNG image data includes an IDAT chunk whose compressed payloads were 286, 716, 1,786, and 15,039 bytes at 16, 32, 48, and 256 pixels. For the DIB frames, each data block has a 40-byte bitmap header and uncompressed 32-bit pixel data plus the ICO transparency mask; the stored bitmap height is twice the displayed height, as used for an ICO DIB with an AND mask.

Reproduce the byte totals

The container arithmetic is 6 bytes for the ICO header, plus 16 bytes per directory entry, plus the sum of the entry data lengths. CanDoYa and thecalcu: 6 + (4 × 16) + 355 + 785 + 1,855 + 15,144 = 18,209 bytes. ConvertICO.com: 6 + (6 × 16) + 270,376 + 67,624 + 16,936 + 9,640 + 4,264 + 1,128 = 370,070 bytes. PNGtoICO.com: 6 + (9 × 16) + 270,376 + 67,624 + 16,936 + 9,640 + 6,760 + 4,264 + 2,440 + 1,720 + 1,128 = 381,038 bytes. Each sum matches the exact local file length.

For the four shared dimensions, the DIB entries sum to 1,128 + 4,264 + 9,640 + 270,376 = 285,408 bytes. Their PNG-encoded counterparts sum to 355 + 785 + 1,855 + 15,144 = 18,139 bytes. Dividing 285,408 by 18,139 gives about 15.7. This is a comparison of the measured frame blocks at those four sizes, not a universal compression ratio.

What this comparison can—and cannot—tell you

For this particular image and these downloaded files, PNG-encoded frames occupy much less space than the corresponding uncompressed DIB frames. Yet the 370,070-byte and 381,038-byte totals also include more entries than the 18,209-byte file, which is why the roughly 20× total-size ratios should not be read as a controlled encoding-only ratio.

If file size matters, inspect both the encoding and the set of sizes actually stored. More frames can improve size coverage for some uses while increasing bytes. If compatibility matters, test the resulting ICO in the exact application or workflow that will consume it; this single size experiment does not establish compatibility or quality across software.

Local byte-level measurements

One 512 × 512 transparent PNG, 17,635 bytes, used for all four uploads. Frame data lengths below are in bytes. PNG rows are PNG image blocks with DEFLATE-compressed IDAT data; DIB rows are 32-bit BI_RGB frames with compression value 0.

All lengths were measured from the downloaded local files and parsed ICO entries. The CanDoYa and thecalcu outputs in this test were fully byte-identical (SHA-256: 152290537D8CB53EA0651F721ACA325D32DD8F8C79A45D9C9FCA4CDD480D0337). This file-level result alone says nothing about shared ownership, infrastructure, or code.

How to check a PNG to ICO result

1. 01
   Keep one source and record its bytes

   For a comparison, use the identical PNG for every converter and record its pixel dimensions, transparency, and exact input byte count. Here the source was 512 × 512 pixels and 17,635 bytes.

2. 02
   Download each ICO before measuring

   Measure the downloaded file locally. A size label shown in a webpage is not a substitute for the byte length of the file you actually received.

3. 03
   Inspect each directory entry

   An ICO is a container: count its entries and inspect each frame's dimensions and encoded image data. Compare like-for-like dimensions before attributing a size difference to encoding.