Which embedded size is selected when ICO is converted to PNG?

Treat ICO as a collection

A Windows icon file can hold multiple images intended for different display sizes and color capabilities. The small entry may be deliberately simplified or adjusted pixel by pixel, while a larger entry can contain finer curves and shading. This means ICO-to-PNG conversion is not always a direct change from one bitmap to another. The converter first has to choose, or allow you to choose, an image from the collection and then write that image as PNG.

Before converting, decide what the PNG is for. A favicon-sized output, an application launcher graphic, and a presentation illustration have different needs. The largest embedded entry may suit a larger display, but a carefully designed small entry can remain clearer at 16 or 32 pixels. Defining the target dimensions prevents the choice from being reduced to whichever file has the greatest width or byte size.

• Identify the final display dimensions before extraction.
• Expect small and large icon entries to contain different design decisions.

Do not assume how the converter selects an entry

A converter might use the first directory entry, the largest dimensions, the greatest color depth, or an internal preference. Another tool may expose every embedded image or ask the user to select one. Without documentation or a visible selector, the behavior must be verified from the result. A successful download only proves that a PNG was produced; it does not identify which source entry supplied its pixels.

Use an icon inspection tool when the source matters, or compare outputs from a file whose entries are visibly different. Record the downloaded PNG's width and height and compare its shape, spacing, and detail with the embedded candidates. If the service provides several files, label them by dimensions immediately. When it provides one, avoid treating its selection rule as universal for other converters or future versions.

• Read any documented selection rule or size option.
• Record the output width and height rather than relying on the preview.
• Keep multi-output extracts named by their pixel dimensions.

Distinguish extraction from scaling

A PNG with large dimensions is not proof that the ICO contained a native image of that size. A tool could select a smaller entry and enlarge it, creating more pixels without adding authentic edge or texture information. Conversely, a tool could reduce a large entry to the requested size. Both operations can alter sharpness. Inspect fine curves, diagonals, corners, and one-pixel features for blur, stair steps, or halos that suggest resampling.

Native small icons can look surprisingly blocky when magnified because they were designed for clarity at actual size. Judge them both enlarged for technical inspection and at their intended display size for usability. If a 16-pixel rendition removes a highlight or widens a line, that may be intentional rather than a defect. Choose the rendition that remains recognizable in context instead of selecting solely by zoomed smoothness.

• Compare output dimensions with known embedded dimensions.
• Inspect diagonals and one-pixel details for evidence of scaling.
• Judge clarity at the real display size as well as under magnification.

Inspect transparency, color, and edge treatment

Icons are commonly viewed against many backgrounds, so transparent boundaries are central to the result. Embedded entries can differ in color depth, transparency representation, and edge treatment. After conversion, place the PNG over a checkerboard, a light background, and a dark background. Look for an opaque rectangle, a white or black fringe, missing semi-transparent pixels, and changes around tight curves or shadows.

Color also deserves a practical comparison. A tiny preview may conceal a shifted accent or reduced contrast, while a highly magnified view can overemphasize a one-pixel difference that users will never see. Compare the source representation and PNG in the same viewer, then place the output in the intended interface. The important question is whether its silhouette, contrast, and transparency remain clear where people will actually encounter it.

• Test transparent edges over both light and dark backgrounds.
• Look for opaque boxes, colored fringes, and lost soft edges.
• Evaluate silhouette and contrast in the real interface.

Validate and document the chosen PNG

Open the downloaded PNG in an independent image viewer and check its actual width, height, color, transparency, and file integrity. Compare several extracted candidates side by side when available. If one output is selected for production, include its dimensions in the filename or asset record so it cannot be confused with another rendition. Keep the original ICO because it preserves the collection that a single PNG cannot represent.

Place the candidate in the webpage, document, or application where it will appear and view it at the exact rendered size. If it looks blurry, crowded, or overly simple, try another embedded size instead of repeatedly scaling the same PNG. For an asset pipeline, document which entry was used and whether any resizing followed extraction. The conversion is complete only when the chosen PNG's origin, dimensions, transparency, and real-world appearance have been checked.

If the PNG will be reused at several sizes, avoid assuming that one extracted rendition is optimal for all of them. Retain separate approved assets when the ICO offers purpose-built small and large versions, and let the interface request the closest suitable size. This preserves intentional pixel-level adjustments and reduces unnecessary scaling in the final product. Verify each exported asset once at its assigned display size before release.

• Verify the downloaded file outside the conversion preview.
• Name or record the approved asset with its pixel dimensions.
• Keep the ICO and note any resizing performed after extraction.