Why ICO to PNG Conversion Looks Blurry, Small, or Has a Background
Last updated: July 8, 2026
When an extracted PNG is tiny, blocky, or surrounded by black or white, the PNG format is rarely the main problem. For example, if your documentation layout enlarges a 16×16 layer to 96×96, the pixelated result comes from upscaling rather than PNG compression. The converter may also have selected the wrong image inside a multi-size ICO or flattened transparency during export.
Start with the PNG's actual dimensions
Open the output's properties and read its pixel width and height. A file that appears large in an editor may only be 16×16 pixels shown at high zoom. If the PNG is 16×16, the converter probably extracted that layer or the ICO contained no larger image.
Do not enlarge it and expect new detail. Nearest-neighbor scaling produces hard square pixels; smoother interpolation softens those squares but cannot restore curves, shading, or line work. Reopen the original ICO and look for 32×32, 48×48, 128×128, or 256×256 layers.
Match each symptom to a cause
| Symptom | Likely cause | First correction |
|---|---|---|
| PNG is unexpectedly tiny | The first or smallest ICO layer was extracted | Select a larger embedded layer |
| Output is pixelated | A small PNG was enlarged beyond native size | Return to the ICO and extract a larger source |
| Output is blurry | Upscaling used smoothing, or the destination rescaled it | Use a layer at least as large as the display size |
| Black or white rectangle | Transparency was flattened, misread, or absent in the source layer | Export with alpha and test another ICO layer |
| Jagged edge or halo | Hard transparency mask, damaged alpha, or edge pixels prepared for one background | Preview on contrasting backgrounds and inspect the source |
| Favicon differs from app icon | Different embedded sizes contain tailored artwork | Compare exact layers rather than scaling one preview |
Why transparency becomes black, white, or solid
Modern icon layers may carry an alpha channel for smooth transparency. Older icons or smaller compatibility layers may rely on a one-bit mask: each pixel is either visible or transparent. A converter that ignores the alpha or mask may replace transparent pixels with a solid background. The same result occurs when an export option deliberately flattens the image.
Test another layer because transparency information can differ inside one ICO. If every layer has a solid background, it may be part of the original artwork rather than a conversion failure. A checkerboard in an editor is only a transparency indicator; preview on white and black to expose pale or dark fringes.
Why favicons and app icons can look different
A favicon is usually displayed in a very small browser context, while a Windows app icon may appear in title bars, taskbars, Start, search, or larger views. Designers often simplify the small rendition so its silhouette stays clear. Enlarging that pixel-tuned favicon layer can look crude even though it is excellent at native size.
Conversely, shrinking a detailed 256×256 app layer to 16×16 may lose thin features or appear muddy. When a precise small rendition exists, use it for that job. For current web or application requirements, check the destination documentation rather than assuming the same asset is accepted everywhere.
Why the largest layer is often safer for editing
A genuine 256×256 or 128×128 layer gives an editor more source pixels than a 16×16 layer and can be resized downward for a preview. That makes it a sensible starting point for annotation, documentation screenshots, and moderate edits. It is not a vector image, however, and it may not match the designer's small-size optical adjustments.
For example, a blogger placing an icon beside a 96-pixel callout should extract a layer at least that large if available. A developer checking the exact 16-pixel tray appearance should inspect the 16×16 layer instead.
Diagnostic checklist before converting again
- Did the ICO contain multiple sizes? Look for a layer list rather than trusting the first preview.
- Which size did the converter extract? Confirm the PNG's numeric width and height.
- Was transparency preserved? Check for an alpha channel or transparent pixels in an editor.
- Did you upscale a small icon? Compare native size with the displayed size.
- Was the output meant for editing, a website, or documentation? Each job may need a different layer.
- Do light and dark previews both look clean? Check halos, jagged edges, and unwanted rectangles.
- Does another embedded layer look different? Small sizes may be intentionally redrawn.
Troubleshooting questions
It may default to the first embedded layer, or 16×16 may be the only layer in the file. Inspect the ICO directory with a tool that exposes available sizes.
You can edit pixels, but first determine whether the source contained transparency. Extracting a layer with intact alpha usually produces cleaner edges than manually deleting a flattened background.
The layer may use a hard transparency mask or carry light edge pixels designed for another background. Inspect a modern alpha-enabled layer and preview it on both light and dark colors.
Final summary
Check the embedded layer and native dimensions before changing compression or scaling. A larger source can be reduced; a tiny source cannot regain detail. Verify transparency on contrasting backgrounds, and remember that the small favicon layer may intentionally differ from the large app artwork.
