PNG to ICO Test: Four Source Shapes, Three Downloaded Outputs

The same input batch did not mean the same icon set

The two server-returned converters used fixed, uncompressed bitmap payload sizes. Their output lengths were therefore identical for every input image: 370,070 bytes at ConvertICO.com and 381,038 bytes at PNGtoICO.com. The second file was 10,968 bytes longer because its directory described three extra layers—20 × 20, 24 × 24, and 40 × 40—not because its source PNG carried more detail.

TheCalcu's four embedded PNG layers totaled 2,900 bytes for the empty transparent image, 5,652 bytes for the tall artwork, 5,853 bytes for the square artwork, and 12,489 bytes for the tiny artwork. These are observed file lengths from this batch. PNG payloads respond to the encoded pixels, while the two DIB sets reserve the same byte count for each selected dimension.

The tall source exposes a geometry difference

For the 120 × 320 narrow-art input, ConvertICO.com and PNGtoICO.com produced the same count of nonzero-alpha pixels at each shared size: 16,048 of 65,536 pixels at 256 × 256, down to 92 of 256 at 16 × 16. TheCalcu's decoded frames instead had 42,648 nonzero-alpha pixels at 256 × 256 and 168 at 16 × 16. At 256 pixels, its count is 2.66 times the DIB result. This is a pixel-count comparison, not a visual-quality score; the saved files and exact per-frame counts are linked in the data.

That discrepancy is a useful prompt to inspect aspect-ratio handling before converting a wordmark or tall mark. It does not by itself prove the cause or tell us what every converter does. For this run, the evidence is limited to the particular 120 × 320 source and downloaded files. The service's saved ICO is the reference here, not a preview or a marketing statement.

The fully transparent input is a byte-level check

All decoded frames from the 320 × 320 fully-transparent.png had zero pixels with alpha above zero across the three complete runs. For example, the 256 × 256 layer had 0 of 65,536 alpha-positive pixels and 65,536 pixels with alpha below 255. Every smaller frame showed the same all-transparent result. That confirms the all-clear input stayed all-clear in these downloaded files; it does not establish how a converter handles partially transparent edges in every image.

The two DIB converters had the same frame payload lengths even on the empty image: the 256 × 256 DIB payload was 270,376 bytes, and the 16 × 16 payload was 1,128 bytes. TheCalcu's matching PNG payloads were 2,364 bytes and 112 bytes. Those are the embedded frame bytes read from the ICO directory, excluding the file header and directory entries.

One CanDoYa file matched a TheCalcu file byte for byte

The retrieved CanDoYa square-art.ico and TheCalcu square-art.ico were both 5,853 bytes and had the same SHA-256 hash: 5BB98F162F8F0BB743A5DA08C7861A08F803C54B1FB2EB15F08F88ABD8538182. Their four PNG-encoded frame payloads and decoded alpha counts also match. This is one exact file-pair observation for one input and these settings. It does not show shared ownership, infrastructure, or code, and CanDoYa's other three sample outputs were not included because a local download could not be verified.

Download the evidence

The CSV has one row per saved ICO frame: source sample, whole-file bytes, number and order of frames, directory dimensions, encoding, compression, payload bytes, alpha-positive pixel count, and non-opaque pixel count. The original ICOs are available by site and filename below. ConvertICO.com and PNGtoICO.com each have four downloaded files; TheCalcu has four; CanDoYa has the square-art file only.

Downloaded file matrix

Whole-file byte counts and frame sizes below were read from local downloads. Full alpha counts and each payload's compression field are in the CSV.

The one CanDoYa file and the matching TheCalcu square-art file have identical SHA-256 hashes. This does not establish shared code or ownership.

• Full frame-by-frame measurement CSV
• ConvertICO.com: square-art.ico
• ConvertICO.com: narrow-art.ico
• ConvertICO.com: tiny-art.ico
• ConvertICO.com: fully-transparent.ico
• PNGtoICO.com: square-art.ico
• PNGtoICO.com: narrow-art.ico
• PNGtoICO.com: tiny-art.ico
• PNGtoICO.com: fully-transparent.ico
• TheCalcu: square-art.ico
• TheCalcu: narrow-art.ico
• TheCalcu: tiny-art.ico
• TheCalcu: fully-transparent.ico
• CanDoYa square-art output
• Source PNG: square-art.png
• Source PNG: narrow-art.png
• Source PNG: tiny-art.png
• Source PNG: fully-transparent.png

What the saved ICOs contain

1. 01
   Keep the source dimensions visible

   The four inputs were intentionally different: square artwork, a tall 120 × 320 image, a 24 × 24 image, and an entirely transparent 320 × 320 image. Their original PNGs are linked below so the test inputs can be checked.

2. 02
   Read the ICO directory and each payload

   The measurements come from the downloaded ICO directory entries and image payloads. DIB frames were parsed from their bitmap headers and pixel alpha bytes; PNG frames were decoded from the embedded PNG data. The page's displayed file-size labels were not used.

3. 03
   Compare matching sizes separately

   Frame counts differ between the three complete converters, so total file bytes alone do not isolate encoding cost. Compare the exact shared dimensions in the CSV and keep the other added sizes visible as part of each site's output behavior.