Favicon Generator

A favicon (short for "favorites icon") is the small image that represents your site in browser tabs, bookmarks, history, search bars and — increasingly — phone home screens. It exists because a tab bar full of identical globe icons is visually indistinguishable noise: the favicon is the only per-site visual browser chrome gives you at 16 or 32 pixels, which makes it the smallest piece of branding you'll ever ship and the one users see most often. Every open tab, every bookmark, every history entry, every search suggestion carries it.

The favicon is also the first thing a user scans for when trying to find your tab among forty others, which is why favicon problems are disproportionately visible: a missing favicon triggers a request to /favicon.ico that 404s on many servers, a default server error icon, or — worst case — your framework's generic logo on a site that looks unfinished. The browser logs the failed request, the bookmark shows a broken image, and the perceived polish of the entire site drops for a bug that takes one tag to fix.

The .ico format is the original, dating to the Windows 95 era: a container that holds multiple images — typically 16×16 and 32×32 in one file — so a browser picks the size it needs from a single download. ICO is still what browsers request implicitly at /favicon.ico, and modern browsers detect the real format from a file's magic bytes rather than its extension, so a PNG placed at /favicon.ico renders fine — but a genuine multi-resolution ICO remains the most compatible choice for older browsers and Windows taskbar pinning.

PNG is the modern default for favicons: it supports full alpha transparency, compresses well at the small sizes involved, and every browser released in the last fifteen years renders it via a <link rel="icon" type="image/png" href="..."> tag. SVG is the emerging format — a single vector file scales to every size without blurring, can be recolored with currentColor, and is supported by all current browsers — but older Safari versions ignore SVG favicons, so SVG should be paired with a PNG fallback, not used alone. The practical stack is: SVG for browsers that support it, PNG for everything else, and an ICO at the root path for legacy default requests.

The sizes exist because the contexts differ. 16×16 is the browser tab and the bookmark bar; 32×32 is the Windows taskbar, the new-tab page thumbnails and high-DPI tab rendering; 48×48 covers some Linux desktop environments and Chrome's bookmark manager. These three were the historical core set and are what a multi-resolution ICO traditionally bundled. Everything above that belongs to mobile and PWA surfaces rather than the browser itself.

Apple devices are the reason modern favicon generation is more than tab icons: iOS Safari's "Add to Home Screen" historically looked for a <link rel="apple-touch-icon"> at 180×180 (180 = 60 points at 3× device pixel ratio), and modern iPhones use 180×180 while iPads use 167×167 and 152×152 depending on the device — Apple will not fall back to a generic screenshot the way Android does, so a site without an apple-touch-icon gets an automatic, often ugly, rendered thumbnail. Android's PWA install prompt similarly reads icons from the web app manifest (192×192 minimum, 512×512 recommended, both with "purpose": "any maskable" variants to survive the shape-cropping different launchers apply — circle, squircle, rounded square).

Modern browsers don't need any markup to show a favicon — they request /favicon.ico by default on page load. That implicit request is a problem in its own right: for a site that has no favicon, every page load generates a 404 for /favicon.ico, polluting logs and server metrics. The fix is an explicit <link rel="icon" href="/favicon.ico"> in the head, which makes the intent clear and lets you point at a real file, or a data-URI favicon that eliminates the request entirely for the smallest possible payload.

The full modern head block covers the surfaces: a 32×32 PNG as the default icon, an SVG with sizes="any" for browsers that support vector, a 16×16 PNG or ICO for the oldest surfaces, the 180×180 apple-touch-icon (which Apple requires as a separate link tag — it does not read the manifest), and the manifest link for PWA icon discovery. Each tag's type attribute should match the actual format, and hrefs should be absolute or root-relative paths; a relative favicon path like href="favicon.png" resolves against the current page's directory, so a favicon that works on the homepage 404s on every nested route.

Generation is a resize-and-export problem: start from a square source image at least 512×512 (ideally a crisp logo on a solid or transparent background — never a photograph, which becomes mush at 16 pixels), then downscale to each target size. Downscaling is done well in a browser with the Canvas API — draw the source into a 16×16 or 32×32 canvas, export as PNG — which is exactly what client-side generators do; the quality caveat is that browser canvas resizing uses a reasonable but not exceptional downsampling filter, so a source with fine detail can alias at small sizes. Design for the smallest size: test your source at 16×16 and 32×32, and if the logo is unreadable there, simplify the mark rather than hoping the larger sizes carry it.

Caching is the final trap. Browsers cache favicons aggressively — Chrome in particular can hold a favicon for a very long time with no standard invalidation — so after regenerating, users may see the old icon for days or weeks. The standard fix is cache-busting via the query string: href="/favicon-32.png?v=4" — the browser treats each versioned URL as a new resource. Common mistakes to avoid: serving a single large PNG as the favicon (it renders fine but wastes bytes on every page load), forgetting the apple-touch-icon so iOS home-screen icons are auto-generated screenshots, making the source image non-square (browsers silently crop, often cutting off the logo), and trusting the manifest alone for Android — Chrome still wants the icon link tags for tab rendering even when the manifest exists.