ICO PNG Resource Extractor

How to use ICO PNG Resource Extractor

Recover the PNG images already stored inside an ICO instead of rescaling one chosen icon. Each exported PNG is its exact original byte range. All directory records, shared ranges, skipped resources and unused file spans stay visible, so a PNG-only extraction is never confused with converting every image in the container.

1. Choose an ICO file, or load the original example containing two genuine PNG images and one deliberately unextracted classic DIB image.
2. Run extraction. Review the PNG count and the separate not-extracted count before downloading.
3. Download the ZIP. Generated image-NNN-WxH.png members retain the original PNG bytes; manifest.json lists every source directory record and byte range.
4. Keep your original ICO. This tool does not edit it, guess which image Windows would select, or convert unsupported resources.

Good to know

• One actual ICO type-1 File from 22 bytes through 2 MiB, with 1–32 complete directory entries. CUR/ANI, EXE/DLL icon resources, ICNS and other containers are unsupported. A local read has a 5-second wait; late Blob reads are ignored because they cannot be forcibly cancelled.
• Only complete static 8-bit RGBA PNG resources are extracted, at most 1 MiB and 256 pixels per side each. PNG width/height must match the directory; zero directory dimensions mean 256. PNG directory color count must be zero, planes 0 or 1, and bit depth 0 or 32. Known PNG data outside this profile refuses the operation; it is not silently relabeled or repaired.
• DIB and unknown resource bodies receive directory/range inventory only. They are not decoded, validated as a particular bitmap format, converted or exported. Classic AND/XOR pixels can depend on the destination background and are not assumed to be ordinary transparent PNG pixels. At least one supported PNG is required; a DIB-only file does not produce an empty success ZIP.
• All ranges must fit after the directory and inside the file. Partial overlaps refuse. Exact shared ranges remain separate source entries and ZIP images, with explicit alias evidence. Gaps and trailing unreferenced bytes are counted and located but not exported. This is indexed PNG recovery, not complete ICO conformance or malware certification.
• Before any native decoding, strict PNG chunk boundaries, CRCs, ordering, dimensions and cumulative limits are checked. APNG, PNG EXIF and compressed profiles/text are excluded by the bounded raster profile. Selected entries, including aliases, may total at most 2,000,000 pixels and 8 MiB encoded bytes. All limits are shared and may reduce one another.
• Each distinct PNG range must decode through Window ImageBitmap at its declared dimensions, sequentially within one 5-second total wait. Each bitmap is immediately closed. An unsupported browser reports its capability limit without a fake result. No Worker image API, Canvas, rescaling, pixel reencoding or color conversion is used. Successful decode is not a full codec, display-color or Windows-rendering certification.
• A same-origin module Worker repeats bounded directory/PNG validation and packs the exact source bytes. It has 10 seconds to prepare the fixed parser and ZIP library, then a separate 2-second computation deadline. Completion, errors and timeouts terminate Worker ownership and clear timers. The complete ZIP is limited to 9 MiB; readable evidence is limited to 200,000 UTF-16 units. Unsupported or over-limit selected data leaves no partial artifact.
• PNG ancillary metadata is preserved because exported bytes are identical to the original resource. This is not anonymization or metadata removal. Review private metadata before sharing the ZIP. Names inside the archive are generated safely; source filenames and unused/opaque bodies are not inserted as paths. No input markup, URL, cursor, executable or image is mounted or opened on the page, and no source is uploaded or stored automatically.