Recover every stored ICO variant
Recover all original ICO entries without resizing, keep equal-size depth variants, and audit exact payloads, alpha policy and complete hashes.
Recover stored artwork before generating new sizes
Sarah asked for each available favicon ICO size as a separate PNG. Jared reported that a smaller icon can be a different design. Valer found that equal-size entries with different depths led a reader to choose an unwanted version. Recovering all original entries provides those choices without silently selecting the largest image.
Select one ICO in T327. Directory order and every supported entry remain, including exact and partial payload aliases. This tool does not generate new sizes, reduce colors, convert a folder or rank visual quality.
Download every variant and its provenance
Download ico-variants.zip. Index-based names distinguish equal-size entries. A standalone ICO retains the exact payload, while only its directory count and payload offset are rebuilt.
| Artifact | Useful task | Preservation boundary |
|---|---|---|
| original.ico | Keep the selected source | All bytes, including gaps and trailing ranges |
| entry-NNNN.ico | Open a specific original variant | Exact payload, header, palette, padding and mask |
| entry-NNNN.png | Use an unscaled raster variant | Exact embedded PNG, or supported DIB raw RGBA |
| ico-inventory.json / ico-variants.csv | Compare every entry and hash | Complete records and formula-safe CSV |
Inspect actual multi-size and same-size inputs
The licensed Pillow fixture named favicon.ico is 15086 bytes. Its three stored 32-bit entries are 16×16, 32×32 and 48×48: 3584 pixels, 15032 payload bytes and nine ZIP members. A separate controlled input contains five 16×16 entries at 1, 4, 8, 24 and 32 bits; all five remain distinct.
- Read stored bits and payload SHA before choosing an image.
- Use full JSON for DIB headers, PNG chunk records and every gap hash.
- Keep the original beside later resizing or editing.
Interpret alpha and metadata precisely
Supported DIBs use a 40-byte BITMAPINFOHEADER, bottom-up BI_RGB and 1/4/8/24/32-bit pixels. The AND mask controls transparency at 1/4/8/24 bits. A 32-bit entry retains stored alpha, including all-zero alpha, without Windows XOR/background compositing or desktop alpha fallback.
Static noninterlaced 8-bit RGB/RGBA PNGs have CRCs, contiguous IDAT including empty chunks, zlib framing/window, expanded size, Adler and filters checked before raw sample decoding. Original PNG bytes remain unchanged. Generated DIB PNGs use controlled filter-zero stored-deflate encoding, without Canvas color transformation.
DIB headers, palettes, padding and masks stay in exact-payload ICOs, not all in newly generated PNG metadata. Unknown private ancillary chunks are retained opaquely. Unsupported public PNG extensions, tRNS, APNG and unsupported DIB/PNG profiles refuse the entire file. Recovery is not anonymization or universal Windows/PNG compatibility.
Apply simultaneous limits and recover the same original
One file allows 20 MiB, 1–256 entries and a filename of 512 UTF-16 units. Each payload allows 2 MiB; aggregate entries allow 16 MiB, 4194304 pixels and 10000 PNG chunks. Aliases count separately. At 256 entries there are 515 controlled ZIP members.
The 4 MiB report and 80 MiB ZIP ceilings are dominated allocation guards, not independently reachable output targets. A malformed entry or excess creates no partial archive. Cancellation discards unfinished output; rerun the same original in a fresh Worker.
Independent production readback checks all 72 native vectors, 805 ZIP members, 368 variants and 4334387 pixels. Actual message Abort at 20/256 completed entries yields no result, and the same source recovers an identical full ZIP. Actual browser acceptance remains a separate channel.
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.