ICO is the Windows icon container, and the favicon is the one mainstream web slot where AVIF is the wrong answer. It packs several small bitmaps — typically 16, 32, and 48 pixels — into a single .ico file, so the browser or operating system can pick the right resolution at render time. This page explains what ICO is, why it survives in the favicon stack, and why you should reach for AVIF for content images while leaving icons alone.
What ICO is
ICO is a multi-image container for small icons, built into Microsoft Windows since version 1.0 in 1985. Three facts define it:
- ICO bundles many bitmaps of different sizes inside one file.
- Each entry stores either raw BMP pixels or, since Windows Vista, a compressed PNG.
- The MIME type is
image/x-icon(the legacyimage/vnd.microsoft.iconis also registered).
Unlike AVIF, ICO carries no modern codec. It is a directory of pixel grids, not a single compressed image. That difference is the whole reason the two formats never compete.
Why it packs multiple sizes in one file
ICO holds several resolutions so the renderer never has to upscale. A single Windows application icon commonly ships these grids:
- 16×16 — taskbar, tab, and dense file lists.
- 32×32 — desktop shortcuts and Alt-Tab.
- 48×48 — Windows Explorer thumbnails.
- 256×256 — high-DPI and large-tile views.
Each grid is hand-tuned to its pixel boundary, so a 16×16 stays legible instead of becoming a blurred downscale of the 256×256. A photographic format such as AVIF solves a different problem: it stores one large image and lets the layout engine resize it. Icons need the opposite — many crisp, purpose-built grids in one bundle.
PNG or BMP inside the wrapper
Every ICO sub-image is either uncompressed BMP or an embedded PNG. The original 1985 design stored only BMP, which kept files small at 16×16 but ballooned at 256×256 — a raw 32-bit 256×256 bitmap is roughly 256 KB. Windows Vista added the option to store each entry as a PNG, so a 256×256 icon drops to a few kilobytes. Modern favicon generators emit PNG-backed entries for the large sizes and BMP for the tiny ones. AVIF never enters this wrapper: no browser decodes image/avif data placed inside an .ico directory.
The favicon role
ICO survives on the web almost entirely because of the automatic /favicon.ico lookup. Browsers since Internet Explorer have requested that exact path at a site's root without any HTML declaration, so an .ico there guarantees a tab icon even on a page that ships no <link rel="icon"> tag. That zero-config fallback is why the format refuses to die.
The trade-off is that ICO is a fixed bitmap. It cannot adapt to dark mode, and it cannot scale like vector SVG. So in 2026 it is the floor of the stack, not the ceiling.
The modern favicon stack — where AVIF plays no part
The current best practice is three files: an SVG icon, an ICO fallback, and a PNG apple-touch-icon. Per the Evil Martians "How to Favicon in 2026" guide, this trio covers every mainstream device:
<!-- Modern browsers: crisp at any size, supports dark mode -->
<link rel="icon" href="/favicon.svg" type="image/svg+xml" />
<!-- Legacy + the automatic root lookup -->
<link rel="icon" href="/favicon.ico" sizes="any" />
<!-- iOS home-screen bookmark, 180×180 -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<!-- Android / PWA install icons -->
<link rel="manifest" href="/site.webmanifest" />
AVIF appears nowhere in this list, by design:
- SVG handles scalable, theme-aware rendering — AVIF is raster, so it cannot.
- ICO handles the legacy and the root-path fallback — AVIF gets no automatic lookup.
- PNG is the only raster format every apple-touch-icon and manifest slot accepts — Safari and Android launchers do not read
image/avificons.
At 16×16, AVIF's container header alone rivals the entire payload, so even where a browser would technically decode it, the bytes work against you. Use PNG or ICO for icons; save AVIF for the photographs and graphics in the page body.
Building an ICO favicon
Generate it from a single high-resolution source — do not down-rez one giant image by hand. A realfavicongenerator.net-style tool, or ImageMagick, assembles the multi-size bundle:
# Combine pixel-tuned PNGs into one multi-size .ico
magick icon-16.png icon-32.png icon-48.png favicon.ico
Keep the file lean: 16, 32, and 48 cover the browser and Windows pin cases, and the whole bundle should land well under 25 KB. Larger 256×256 art belongs in PNG or SVG, declared separately.
ICO versus AVIF at a glance
These two formats sit at opposite ends of the image stack:
- Purpose — ICO bundles tiny UI icons; AVIF compresses one large content image.
- Compression — ICO leans on PNG/BMP per entry; AVIF uses the AV1 codec for roughly half a JPEG's bytes.
- Scaling — ICO ships fixed grids; AVIF is resized by the layout engine.
- Web slot — ICO owns
/favicon.ico; AVIF owns<img>and<picture>content.
For the body images on the same page as your favicon, convert them with the browser-based tools here: Convert JPG to AVIF, Convert PNG to AVIF, Convert AVIF to JPG, and Convert AVIF to PNG.
FAQ
Should I use AVIF for my favicon? No. Favicons need the /favicon.ico fallback, SVG scaling, and PNG apple-touch-icons — none of which AVIF provides.
Can an ICO file contain an AVIF image? No. ICO entries are BMP or PNG only; no browser decodes AVIF placed inside an .ico.
Is ICO better than WebP or AVIF for the web? Only for the favicon slot. For every content image, AVIF and WebP compress far smaller at higher quality.
Do I still need an ICO file in 2026? Yes, as the legacy and root-lookup fallback beneath an SVG primary icon and a PNG apple-touch-icon.
Further reading
- How to Favicon in 2026 — Evil Martians
- Favicon, ICO, and the
<link rel="icon">spec — MDN - AVIF Format — the format for content images, not icons
- SVG Format — the scalable primary favicon
- Image SEO Best Practices — brand-asset and favicon SEO
- AVIF Optimization — compressing the content images on the page