Size and color depth are part of icon provenance
An ICO can store different artwork at the same dimensions; preserve every entry before selecting a design or interpreting transparency.
One displayed raster is not the whole icon
The direct user questions describe separate-size recovery, different small designs and equal-size depth selection. An ICO can contain different artwork at the same dimensions. Converting only the first displayed raster cannot recover the other stored originals.
T327 is one all-entry recovery workflow. A size, depth or PNG versus DIB payload does not become another independent tool.
Keep choices visible without a quality ranking
Complete reports expose directory index, dimensions, stored bits, payload offset and hashes. Naming only by size would conceal equal-size alternatives.
| Question | Evidence | Limit |
|---|---|---|
| Is this different artwork? | Every unscaled PNG and payload SHA | No inferred best-quality ranking |
| Was the payload changed? | Original and exact-payload single ICO | Standalone count/offset are rebuilt |
| Why does a viewer show different alpha? | Stored alpha and original AND policy | No Windows background/XOR or zero-alpha fallback inference |
| Did metadata survive? | Original/single ICO and full records | DIB-derived PNG does not copy all DIB metadata |
Aliases and trailing bytes belong to the original
Entries may share all or part of their stored bytes. Each stays in order and is charged separately against payload and pixel budgets. Sorting or deduplicating by dimensions would remove a legitimate choice.
Gaps and trailing bytes remain in original.ico with complete offset/length/SHA evidence. Their contents are not interpreted or executed. Permitted unknown private PNG chunks remain byte exact.
- Keep the original and inventory for later audits.
- Retain distinct entry names when selecting a design.
- Treat resizing, metadata cleaning and color management as their own workflows.
Bound the claim to actual evidence
The supported DIB/PNG subset is explicit. Unsupported entries are refused atomically rather than omitted from a successful-looking ZIP. Raw stored RGB/RGBA is the comparison target, not a platform-rendered screenshot.
Independent Pillow/struct/zlib/ZIP readback verifies every output byte and sample for the supplied specimens. Real Worker cancellation and same-source recovery need no SharedArrayBuffer. That does not certify every Windows viewer, browser build or source icon on the internet.
References
- Valer / original ICO recovery request
Complete original author body and relevant answers read on 2026-10-07. Equal-size32/8/4-bit variants must remain distinguishable; export every entry plus stored-depth evidence. No inferred quality ranking.
- Jared Armstrong / original ICO recovery request
Complete original author body and relevant answers read on 2026-10-07. Distinct smaller icon images are needed; full per-file entry export delivers that choice. Folder batch remains a gap.
- Sarah / original ICO recovery request
Complete original author body and relevant answers read on 2026-10-07. Each available ICO size as a separate PNG; single-file complete endpoint.
- W3C PNG Recommendation
Selected framing/CRC/zlib rules read; explicit subset, no universal conformance.
- Pillow ICO documentation
Default-largest behavior read; per-entry originals and PNGs independently checked with Pillow12.3.0.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
Extract every ICO variantRecover every stored ICO entry as an exact-payload single ICO and unscaled PNG, preserving equal-size variants, depth, order and full hashes.
Select one local ICO and recover every directory entry in its original order, including different images at the same size or depth. Download the original, one exact-payload ICO and unscaled PNG per entry, plus complete JSON/CSV in one ZIP.
Steps
- Select one existing ICO and keep a separate original.
- Run and inspect every size, stored depth, container and offset row.
- Download ico-variants.zip and choose the entry-NNNN PNG or exact-payload ICO you need.
- Use the complete JSON/CSV to audit original payloads, alpha policy, gaps and hashes.
Capabilities and limits
- One ICO file up to 20 MiB, with 1–256 entries and a filename up to 512 UTF-16 units. Entry dimensions are 1–256 pixels; a zero directory byte means 256. CUR, ANI and other containers are unsupported.
- Each indexed payload allows 2 MiB; aggregate payloads allow 16 MiB, with at most 4194304 pixels and 10000 embedded PNG chunks. Shared or partially overlapping payloads are retained and charged separately for every directory entry. All budgets apply together.
- DIB support is limited to a 40-byte BITMAPINFOHEADER, bottom-up BI_RGB, one plane and 1/4/8/24/32-bit pixels. Palettes, row padding, exact XOR/AND sizes and directory dimensions/depth are checked. Top-down, RLE, bitfields and other headers are refused.
- For 1/4/8/24-bit DIB, the AND mask controls transparency. A 32-bit DIB retains its stored alpha, including all-zero alpha, without Windows XOR/background compositing or desktop alpha fallback. The original AND mask remains in the exact ICO payload.
- Embedded PNG support is static noninterlaced 8-bit RGB/RGBA. CRC, contiguous IDAT including empty chunks, zlib window/framing, expanded size, Adler and filters are checked before raw sample decoding with DecompressionStream. Original PNG bytes are unchanged; there is no Canvas color transform.
- Selected PLTE/gAMA/cHRM/sRGB/sBIT/pHYs/bKGD/tIME/tEXt framing, order and values are checked. Unknown private ancillary chunks remain opaque and byte exact. Other public extensions, indexed/grayscale/interlaced PNG, tRNS and APNG refuse the whole ICO; no universal PNG or color-management conformance is claimed.
- The ZIP contains original.ico, every entry-NNNN.ico, every entry-NNNN.png, ico-inventory.json and formula-safe ico-variants.csv. A 256-entry file produces 515 controlled members. The 4 MiB report and 80 MiB ZIP ceilings are dominated allocation guards, not independently reachable output promises.
- Original headers, palettes, padding and masks stay in single-entry ICOs. Generated DIB PNGs contain raw pixels without copying every DIB metadata field. Gaps and trailing bytes remain in the original with offset/length/SHA evidence. This is recovery, not anonymization or a best-quality ranking.
- Browser-local processing without upload, URL fetch, user metadata execution or remote services. A malformed or unsupported entry refuses the whole file; no partial ZIP is offered.