Change PNG to ICO in your browser

What the downloaded files actually contain

We created three opaque PNGs from scratch: wide, 64 × 32; tall, 32 × 64; and square, 64 × 64. Each has a green left half, RGBA [24,77,65,255], and an orange right half, [224,102,52,255]. They contain no source padding. We selected all seven sizes and downloaded the output from the converter above, then opened the saved ICO bytes with a separate Python decoder.

The wide ICO is 4,671 bytes, the tall ICO 4,509, and the square control 4,444. Each directory has seven entries: 16, 24, 32, 48, 64, 128 and 256 pixels. The decoder checked each entry against its embedded PNG dimensions, rejected overlapping or out-of-range payloads, and extracted every frame. These are file measurements from this run, not estimates of another image's download size.

For the wide image at 16 pixels, the nonzero-alpha box is x=0–15, y=4–11. Rows 0–3 and 12–15 are clear. The tall image uses x=4–11, y=0–15 instead. The square control fills x=0–15, y=0–15. All three match their source proportions; no side was cropped to make the square.

The corner sample gives a second check. Wide and tall frames decode to [0,0,0,0] at (0,0), whereas the square control gives [24,77,65,255]. The control separates padding added by the fit operation from transparency already present in a source file. All decoded pixels in these particular block-color samples were either fully clear or fully opaque. That does not predict the alpha values of diagonal or soft-edged artwork.

Why the padding has this size

The fit uses one scale factor for both axes: s=min(N/W,N/H), where W and H are the decoded source dimensions and N is the selected square-frame size. Content width is W×s and height is H×s. Center offsets are x=(N−W×s)/2 and y=(N−H×s)/2. These equations describe this converter's method; they do not describe every PNG-to-ICO service.

For the saved wide source, W=64, H=32 and N=16. The calculation is s=min(16/64,16/32)=0.25, giving 16 × 8 content and offsets x=0, y=4. The decoder independently found that same box. With the tall source, W=32 and H=64, the calculation gives 8 × 16 content at x=4, y=0. With the square source, both offsets are zero.

This run deliberately uses aspect ratios that map to whole pixel boundaries at every selected size. Other dimensions can place an edge between pixels. The browser then resamples the artwork, so a decoded alpha boundary may contain partially transparent pixels. The setting requests high-quality canvas smoothing; exact encoded byte sizes and edge pixels can vary between browser implementations.

Repeat the same test

Start with the saved source, not a screenshot of the diagram. The original PNG and actual ICO are separate files. The 16px PNG is extracted from the ICO payload; the CSV.gz records every RGBA pixel of every decoded frame, including the clear ones.

• wide: source PNG · actual ICO · extracted 16px frame · all decoded pixels
• tall: source PNG · actual ICO · extracted 16px frame · all decoded pixels
• square: source PNG · actual ICO · extracted 16px frame · all decoded pixels

All directory entries and pixel samples (JSON) · Independent Python decoder · Complete experiment and local converter package

1. Download wide.png. Choose it in the converter, keep all seven sizes checked, create the ICO and save the download.
2. Install Python and Pillow, then run the decoder against the saved file. It reads the directory and each embedded PNG rather than trusting the preview.
3. Compare the frame-16.png output and measurements.json. The nonzero-alpha box should have the same shape for this sample. Browser PNG compression can produce different byte counts, so compare dimensions and decoded pixels before treating byte differences as a failure.
4. Repeat with tall.png and square.png. Keep the chosen sizes unchanged. A single-size export is a different file and will have a different directory count.

python -m pip install pillow
python decode_ico.py wide.ico --out decoded-wide

The decoder also checks directory ranges. In a private control, we changed one offset to point beyond the end of the file; it stopped with an out-of-range error instead of returning an invented frame. The public ICOs above are the unchanged successful downloads. The package includes the actual converter source so the fit and packing method can be inspected.

Questions and answers

What does this converter support?

Still PNG input and one ICO output, with your selected square sizes. It uses PNG-encoded frames and preserves transparent space. It rejects animated PNG, malformed PNG input and files above the displayed limits. It does not create a legacy multi-bit-depth icon set, batch-process files, install icons in Windows, or change this site's favicon. The saved files were decoded and checked; Windows Explorer installation and every consuming application were not tested.

For vector artwork rather than a PNG source, see the separate SVG to ICO frame inspection. It answers a different input-format question.

Why your 1px line fades at 16px

When a one-pixel stroke in a 64 × 64 PNG was reduced to a 16 × 16 ICO frame, its sampled alpha peaked at 63. That is one quarter of 255, so the stored pixel retained one quarter of its opacity; how faint it looks depends on the display and scale. The native-size line and four-pixel control reached 255 in these samples.

Three things to try

• Moving the 64 × 64 single-pixel line by one source pixel did not restore its opacity: x=31, x=32 and x=33 each peaked at alpha 63 in the 16 × 16 frame.
• If you need a fully opaque line in this test, start with a four-pixel stroke. The vertical-width4 sample reached alpha 255 at 16px.
• Keep a 16 × 16 source when that is your target size. The native16-x8 sample stayed at alpha 255 in its 16px frame.

The 16px scanlines

We placed vertical strokes at x=31, x=32 and x=33 in separate transparent 64 × 64 PNGs. A horizontal stroke at y=31 checked the other direction. Each painted pixel was RGBA [24,77,65,255]; the background was [0,0,0,0].

Two controls help put the results in context: one 64 × 64 source had four painted columns, x=32..35; another was already 16 × 16, with a one-pixel stroke at x=8.

All seven frame sizes were selected in the converter. We downloaded each ICO and decoded its saved bytes. The table reports the 16 × 16 frame. “Nonzero positions” means the sampled pixel had alpha greater than 0; it does not tell us whether the line looks readable.

The decoded records, including directory entries and alpha bounds, are in browser-measurements.json. The evidence package contains the six source PNGs, six saved browser ICOs, a decoder and measurement records.

Shifting the reduced vertical stroke moved its sample from x=7 to x=8. It did not raise the peak alpha: all three peaked at 63. At each listed position, the decoded pixel was [24,77,65,63]; other pixels on those scanlines had alpha 0.

The four-column control and native-size line both produced [24,77,65,255] at (8,8).

The thin line survived pixel-perfect, no blur. But it was so washed out it looked like the icon was never drawn. Pixels all there, color gone — useless if you can't see it.

Files and rerun steps

The evidence package contains the source PNGs, local reproduction ICOs, extracted frames, pixel CSVs and scripts. The local reproduction uses a different renderer; its results are kept separate from the browser exports.

Use cases.json for the source coordinates and hashes, local-runs.json for run times, and local-measurements.json for the local scanline readings. The ICO decoder checks directory offsets and embedded PNG dimensions. The scanline reader reads the 16px payload pixels.

To repeat the local run, extract the package, install Pillow and the pinned canvas dependency, generate the sources with make_sources.py, and run the local adapter. Then run the decoder and measure.py to regenerate the measurement JSON and scanline CSVs.

To make a fresh browser comparison, upload the same PNGs to this converter, keep the displayed frame sizes selected, save each download and compare its decoded entries with browser-measurements.json.

Questions the scanlines answer

Did the reduced line disappear?

No. Its sampled scanline still had a pixel with alpha 63. That confirms a stored pixel, not that the line is easy to see.

Does shifting a one-pixel source line fix its opacity?

Not in these samples. Lines at x=31, x=32 and x=33 all peaked at alpha 63 in the reduced frame.

Was the 16px frame missing from the ICO?

No. The decoder found a 16 × 16 PNG payload in each saved ICO, alongside the other selected sizes.

Known boundary: alpha 63 is a stored pixel value, not a visibility threshold; these are browser exports, not installation tests, and other artwork shapes and consuming applications were not tested.

For more on partial alpha in small frames, read the semi-transparent PNG pixel guide.