How to use
Drop a square source image (PNG, JPEG, WebP, SVG via browser decode) — ideally **512×512 or larger**. The tool downscales it to each ICO size (16, 32, 48, 64, 128, 256 px), encodes each as PNG, and packs them into a single `.ico` container using the Windows ICONDIR format. You can toggle individual sizes on and off — most modern browsers only render 16 and 32 (the 16-px favicon and the 32-px high-DPI variant), so a 16/32-only ICO is typically 1–3 KB while the full 6-size pack is 15–40 KB. The download is a single `favicon.ico` file ready to drop into your project's `public/` or `static/` directory.
For a complete favicon setup, enable the **favicon kit** option: alongside the `.ico`, the tool produces PNG files for `apple-touch-icon` (180 × 180 px), Android Chrome (192 × 192 px and 512 × 512 px for the high-DPI home-screen variant), and a `site.webmanifest` snippet pre-filled with the correct names, sizes, and MIME types. Drop them all in your site root and add the standard `<link>` tags from the included snippet to your HTML `<head>` — modern browsers, iOS Safari, and Android Chrome home-screen installs will all pick up the right icon. Everything runs in your browser; the source image never reaches a network endpoint, so it is safe to use with unpublished brand assets.
Examples
Minimal modern setup — 16/32 only
Input
source: logo-512.png (512 × 512, solid background)
sizes: 16 ✓, 32 ✓, 48, 64, 128, 256
favicon kit: off
Output
favicon.ico — 2.1 KB
contains: 16×16 PNG + 32×32 PNG
total ICO entries: 2
HTML to add to <head>:
<link rel="icon" href="/favicon.ico" sizes="any">
That's it. Modern Chrome / Firefox / Safari will pick this up,
and it'll show in the browser tab and bookmark list.
For a side project, blog, or internal tool, **16/32-only is enough**. Modern browsers stopped picking the larger sizes from the ICO container years ago — the 48 / 64 / 128 / 256 sizes only mattered for Windows file-explorer icon previews back when web apps registered themselves as native file handlers (a feature rarely used today). The single `<link rel="icon" href="/favicon.ico" sizes="any">` tag, plus the `favicon.ico` file at the URL root (`/favicon.ico`, *not* a subdirectory), is what every browser still auto-discovers. The `sizes="any"` attribute tells browsers "this single file has whatever sizes you need, just grab it" — it suppresses the rare "favicon size mismatch" warning some browsers issue.
Full favicon kit — iOS + Android + manifest
Input
source: brand-logo-1024.png (1024 × 1024, transparent bg)
sizes: 16, 32 (in .ico)
favicon kit: on
site name: "Utilrepo"
Output
Generated files:
favicon.ico (1.8 KB)
apple-touch-icon.png (180 × 180, 11 KB)
android-chrome-192x192.png (192 × 192, 13 KB)
android-chrome-512x512.png (512 × 512, 64 KB)
site.webmanifest (250 B)
HTML snippet for <head>:
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
For a serious product, marketing site, or PWA, the favicon kit is what you want. The `apple-touch-icon.png` is what iOS Safari uses when a user adds your site to their home screen — without it, iOS falls back to a generic screenshot of the page, which looks unprofessional. The 192 / 512 Android Chrome icons are referenced from `site.webmanifest`, which Chrome reads when a user installs a PWA. The manifest also declares the app name, theme color, and display mode (`standalone` for full-screen, `browser` for tabbed) — you can edit it after download to fill in additional metadata. For deeper PWA support you may want a separate "maskable" icon (added padding so it renders nicely inside Android's circular icon mask); that is outside this tool's scope.
When you only have a small logo — 64×64 source
Input
source: legacy-logo.png (64 × 64, transparent bg, hand-drawn at this resolution)
sizes: 16 ✓, 32 ✓, 48, 64 ✓, 128, 256
warning: "source is smaller than 256 — upscaling 128 / 256 not recommended"
Output
favicon.ico — 3.4 KB
contains: 16×16, 32×32, 64×64 (skipped 128 / 256)
The 16 and 32 entries are downscaled — sharp.
The 64 entry is at native resolution — sharpest.
Larger sizes were not generated because upscaling produces blur.
Downscaling looks good; upscaling does not. A 64-px source image should not generate 128 / 256 entries because the upscaled output will look soft and pixelated next to the crisp downscaled smaller sizes — your icon will look "inconsistent" depending on which size the browser picks. The tool warns when source resolution is below the requested ICO size and skips those entries by default. The fix is to redraw or vectorize the logo at higher resolution; a tracing tool like Inkscape or Adobe Illustrator can vectorize a small raster logo well enough for icon use. If the original artwork is truly lost, accept the limitation and ship a 16/32/64-only ICO.
FAQ
What is the ICO file format and why does it still exist?
**ICO** is a Microsoft container format introduced with Windows 1.0 in 1985. The original spec stored uncompressed BMP-style bitmaps in 16, 32, and 48 px sizes for system icons (folders, drives, the Start menu). With Windows Vista (2007), Microsoft extended the format to allow **PNG-encoded payloads** for sizes ≥ 256 px, dramatically reducing file size for high-resolution icons. The format survived into the web era because **Internet Explorer required `/favicon.ico` at the site root** since IE 5 in 1999 — Netscape later adopted the convention to maintain compatibility. Every browser since has continued to auto-request `/favicon.ico` even without a `<link rel="icon">` tag in HTML, which is why most sites still ship one as a fallback. Modern browsers also accept PNG/SVG favicons via explicit `<link>` tags, but the `.ico` remains the lowest-common-denominator default.
ICO vs PNG vs SVG favicon — which one should I use?
For **maximum compatibility**: ship a `.ico` at `/favicon.ico` as the fallback, plus explicit `<link>` tags for PNG (apple-touch-icon for iOS, Android Chrome 192/512) and optionally SVG. For **modern-only sites** (no IE / legacy Edge support needed): a single SVG favicon via `<link rel="icon" type="image/svg+xml" href="/favicon.svg">` works on Chrome 80+, Firefox 41+, Safari 12+, and is the smallest file (often < 1 KB). SVG favicons also support `prefers-color-scheme` so the icon can adapt to dark/light mode — a feature no ICO can match. The trade-off is SVG complexity: a complex multi-layer SVG may not render correctly at 16 px because tiny details disappear. Test in Chrome DevTools at 16 × 16 zoom before shipping. **Recommendation**: ICO + apple-touch-icon PNG covers 99% of cases; SVG is the bonus for modern users.
Why is the favicon at `/favicon.ico` and not in `/static/icons/`?
Historical default. Internet Explorer 5 (1999) hard-coded the path `/favicon.ico` and **issued an automatic GET request** for it on every page load, regardless of whether HTML mentioned it. Other browsers copied the behavior for compatibility. Even today, Chrome / Firefox / Safari all auto-request `/favicon.ico` if no `<link rel="icon">` is found in HTML — which means putting your favicon at `/static/favicon.ico` requires explicit `<link rel="icon" href="/static/favicon.ico">` to override the default lookup, and a 404 for the implicit `/favicon.ico` will still hit your server every page load. The pragmatic approach: keep `favicon.ico` at the root URL even if your other static assets live elsewhere. Modern static-site generators (Next.js, Gatsby, Hugo, Astro) make this trivial by copying any file placed in `public/` or `static/` to the URL root automatically.
How do browsers decide which ICO size to display?
Each browser embeds its own rules but they converge on **"pick the smallest size ≥ display target, or the largest available if all are smaller"**. The display target depends on context: browser tabs render at 16 × 16 (or 32 × 32 on high-DPI displays), bookmark lists at 16, history dropdowns at 16, the address-bar lock icon at 16, OS-level shortcuts (Windows taskbar pin, macOS dock) at 32 or 48, and high-DPI versions of all the above at 2× / 3× scale. Chrome and Firefox use the closest-match algorithm; Safari prefers 32 if available and falls back to 16. Edge respects the ICO's declared `bitCount` to prefer 32-bit (alpha-channel) entries when multiple bit-depths exist. The pragmatic rule: **always include both 16 and 32**, ignore the larger sizes for browser favicons (use PNG `apple-touch-icon` for iOS instead), and never trust a single size to look right everywhere.
My favicon does not update after I deploy a new one — why?
Browsers cache favicons aggressively — far more than other assets. The `/favicon.ico` request often bypasses cache-busting query strings because of how the browser's favicon prefetcher works, and some browsers cache the favicon for 24 hours or longer regardless of HTTP `Cache-Control` headers. The reliable fix is to **rename the file** (e.g. `favicon.v2.ico`) and update the `<link>` tag accordingly — most static-site generators handle this automatically via content-hashed filenames. For the canonical `/favicon.ico` location which cannot be renamed without breaking the implicit request, the workaround is to add `?v=2` to the `<link href>` and trust that users will eventually refresh; corporate users on enterprise proxies may still see the old one for days. During development, Chrome DevTools → Application → Storage → Clear site data forces an immediate refresh.
Should the favicon source be square, and what aspect ratio works?
**Yes, always square**. Non-square sources get stretched or cropped by the encoder; both look bad. Aim for an aspect ratio of exactly **1:1** at 512 × 512 or higher. The icon's visual content should sit inside a slightly smaller "safe area" with some breathing room — historically about 10% padding on each side — because the icon appears in a wide variety of contexts (tab, bookmark, taskbar, home screen) and tight crops feel cramped. iOS in particular adds its own rounded-corner clip and shadow, so contents at the absolute corner will get clipped. The maskable-icon spec (W3C, 2019) formalizes this padding with a documented safe-area-of-the-circle for Android home-screen circular icon masks — 40% padded for full safe rendering inside the circular mask. For a normal favicon (non-maskable), 10–15% padding is the comfortable middle ground.
Related concepts
The **favicon convention** is one of the longest-lived informal standards in the web ecosystem. Introduced by Microsoft in **March 1999** when Internet Explorer 5 shipped with auto-detection of `/favicon.ico` for bookmarked sites, it predates HTML4 itself and survives essentially unchanged in 2026. The name is a contraction of "favorites icon" — Internet Explorer's bookmarks were called "favorites", and the auto-fetched icon was the *favorites icon*. Within months, Netscape and Opera adopted the same path-based auto-detection, and the convention became permanent. HTML4 added `<link rel="shortcut icon">` in the same year to allow explicit override; modern HTML uses `<link rel="icon">` (the `shortcut` prefix is deprecated but still accepted). Apple introduced the **apple-touch-icon** convention with iPhone OS 1.1.3 in 2008 to give iOS home-screen icons a higher-resolution source; Google followed with **Android Chrome icons** in 2014 as part of the early PWA push.
The **ICO container format** itself reflects 1985-era Microsoft engineering decisions. The header is little-endian (Intel x86 native order), the entry table uses fixed 16-byte records, and the width/height fields are single bytes — meaning sizes above 255 px require a quirky encoding where 0 means 256 (sizes above 256 are not representable). The PNG-payload extension introduced in Vista works around the size limit only because the PNG header itself contains the true dimensions, which Windows and modern browsers read from inside the embedded PNG rather than the ICO directory entry. Most modern icon-generation libraries (this tool included) emit PNG payloads exclusively because they are smaller than the original BMP-style payloads — uncompressed 256 × 256 RGBA is 256 KB, while the equivalent PNG is usually under 30 KB. Microsoft's **.cur** (cursor) format shares the same container structure with two extra bytes encoding hotspot coordinates.
Three adjacent **icon and asset concepts** intersect with favicon work. **SVG favicons** (supported since 2019 across major browsers) are the modern alternative: a single file that scales to any size without quality loss and can respond to `prefers-color-scheme` via CSS embedded in the SVG; the trade-off is that SVG favicons cannot represent the rich color and gradient detail that complex brand logos sometimes require, because they get rendered at 16 × 16 alongside Chinese characters and emoji in browser tabs. **Progressive Web App (PWA) manifests** (W3C standard, 2016) formalize what apple-touch-icon started: a JSON file (`site.webmanifest` or `manifest.json`) that declares name, icons, theme color, and display mode for installable web apps. The Lighthouse audit in Chrome DevTools checks for both a valid favicon and a complete manifest — fixing these is often the first PWA-readiness win. Finally, **maskable icons** (W3C, 2019) introduce a documented safe-area inside icons so that Android's circular icon clip-mask does not chop off content; declaring `"purpose": "maskable"` in the manifest tells Chrome the icon is designed with this padding, avoiding the "icon-with-white-square-border" fallback Android otherwise applies.
