Favicon & App Icons: Complete Guide to Sizes and Formats

The favicon is one of the web's most quietly ubiquitous design elements. Every browser tab displays one, every bookmark bar relies on them, and every progressive web app needs an entire family of them to function properly. Yet the story of how a single 16×16 ICO file grew into a sprawling ecosystem of platform-specific icons, vector formats, and manifest declarations is one that most developers never pause to appreciate — until they find themselves debugging why their site shows a blank square on someone's iPhone home screen.

The Evolution from a Single ICO File

When Microsoft shipped Internet Explorer 5 in 1999, it introduced a small but lasting convention: if a file named favicon.ico existed in a website's root directory, the browser would display it alongside the page title in the Favorites menu. No HTML markup was required. The browser simply made a request to /favicon.ico and, if it found something there, used it. The name itself — a portmanteau of "favorite" and "icon" — reflected its narrow original purpose, and for nearly a decade that convention held steady. A 16×16 pixel grid rendered in the ICO format, often with only 256 colors and a 1-bit transparency mask, constituted the entire favicon story. Web designers treated it as an afterthought, something assembled in the final minutes before a site launch.

The landscape shifted as browsers multiplied and devices diversified. Firefox, Safari, and Chrome each began rendering favicons in tabs rather than just bookmark lists, raising the bar for visual quality. Retina displays arrived and doubled pixel density overnight, turning a 16×16 favicon into a blurry smudge unless a 32×32 alternative was available. Mobile operating systems introduced home screen shortcuts that demanded much larger, higher-fidelity images. The single ICO file that once handled everything was suddenly inadequate, and developers found themselves needing to produce an entire family of icons from one source graphic — a task that tools like the Favicon Generator were specifically built to solve.

Why Browsers Need So Many Icon Sizes

The proliferation of icon sizes is not arbitrary; each one serves a distinct rendering context. Desktop browser tabs typically display icons at 16×16 CSS pixels, but retina screens need a 32×32 asset to avoid upscaling artifacts. Windows taskbar shortcuts look best at 48×48, and some platforms — Google TV, for instance — request 96×96. Bundling these four sizes into a single ICO file remains a practical approach for desktop coverage because the ICO format has a unique capability: it can embed multiple resolutions in one container, allowing the browser to select the most appropriate variant without additional network requests.

Apple's ecosystem introduced its own requirements when the iPhone arrived. When a user taps "Add to Home Screen" in Safari, iOS looks for an apple-touch-icon — a PNG rendered at 180×180 pixels on current iPhones. Historically, Apple specified separate sizes for different devices: 120×120 for older iPhones, 152×152 for iPads, and 167×167 for iPad Pros. In practice, providing a single 180×180 PNG covers every Apple device because iOS scales the image gracefully downward. Android and Chrome follow the Web App Manifest specification, which expects at least two icon sizes: 192×192 for home screen placement and 512×512 for PWA splash screens and potential Play Store listings. Windows carved out its own territory with live tiles in Windows 8, requiring 70×70, 150×150, and 310×310 images declared through a browserconfig.xml file. While live tiles have faded in importance, a 150×150 tile still improves the experience for users who pin sites to the Windows Start menu. The pattern across all these platforms is consistent: start with a high-resolution source image — 1024×1024 is ideal — and let automated tooling produce every derivative. The Image Resizer makes this straightforward, generating every required dimension from a single master graphic in seconds.

How Browsers Decide Which Icon to Use

The icon selection algorithm varies across browsers but follows a general hierarchy. When multiple <link rel="icon"> tags are present in the HTML, the browser evaluates them based on declared sizes attributes and format preferences. Chrome, for example, prefers SVG if available, then selects the closest size match to its rendering context from the available PNG options. If no explicit link tags exist, the browser falls back to requesting /favicon.ico from the site root — a silent convention that persists to this day.

Safari on iOS ignores standard favicon declarations entirely when building a home screen shortcut; it considers only apple-touch-icon links. Android's Chrome looks to the Web App Manifest first and falls back to HTML link tags only if no manifest is present or the manifest's icons array is incomplete. This layered selection process explains why a complete favicon implementation requires declarations across HTML, the manifest file, and potentially a browserconfig.xml as well — each platform looks in different places, and none of them consult all sources uniformly. The practical implication is that testing on actual devices matters far more than checking a single desktop browser. What renders perfectly in Chrome on macOS may be entirely absent on an Android home screen or appear as a blurry placeholder on an iPad.

Apple Touch Icons and Their History

Apple's approach to web icons has always been opinionated, and understanding its history helps explain why certain requirements feel so rigid. When the original iPhone launched in 2007, there was no App Store — web apps were the intended way to extend the device's capabilities. Apple needed these web shortcuts to feel native alongside built-in apps, which meant icons had to follow a specific visual language. The company required PNG format, applied its own gloss effect automatically — a rounded-corner mask with a reflective sheen — and expected a rigid set of sizes.

Over the years, Apple deprecated the automatic gloss effect in favor of flat icons specified with apple-touch-icon-precomposed, and eventually dropped the distinction altogether. Modern iOS applies only corner rounding, leaving the visual treatment entirely to the designer. The file requirements, however, have remained strict: PNG format, square aspect ratio, no transparency (iOS fills transparent areas with black), and 180×180 pixels as the canonical size for current devices. Omitting the apple-touch-icon is one of the most common favicon mistakes on the web. When Safari cannot find one, it generates a low-quality miniature screenshot of the page instead, which looks decidedly unprofessional next to polished native app icons. If your source image is in a format other than PNG, the Image Converter can transform it to the correct format and dimensions in a single step.

Android Adaptive Icons and Maskable Safe Zones

Android's approach to home screen icons has undergone dramatic evolution. Prior to Android 8 (Oreo), icons were simply rectangular PNGs displayed at whatever shape the launcher dictated — some launchers used circles, others used rounded squares, others used "squircles." This inconsistency produced visual chaos on home screens, with icons of varying shapes and padding levels sitting awkwardly side by side.

Google's solution was adaptive icons: a two-layer system consisting of a foreground image and a background color or image, combined at runtime by the launcher into whatever shape the device manufacturer has chosen. For web developers, the relevant concept is the maskable icon, which is the PWA equivalent of an adaptive icon. A maskable icon designates the central 80% of the image as the "safe zone" where all meaningful content — logos, text, symbols — must reside. The outer 20% serves as a bleed area that the operating system may clip away when shaping the icon into a circle, rounded rectangle, or any other contour.

Failing to provide a maskable variant has a visible penalty. Android will shrink a standard icon to fit within the safe zone and surround it with a white circle, producing a result that looks amateurish compared to natively installed apps. The Web App Manifest supports distinguishing between standard and maskable icons through the purpose field — you can declare an icon as "any" for general use, "maskable" for adaptive contexts, or "any maskable" if a single image serves both roles. In practice, creating separate assets for each purpose yields the best visual result because the design constraints for a maskable icon (generous padding, no content near edges) often conflict with the desire for a bold, full-bleed icon in standard contexts.

PWA Manifest Icon Requirements

The Web App Manifest is the linchpin of progressive web app functionality, and its icons array determines whether a browser considers your app installable. Chrome requires at least one 192×192 icon and one 512×512 icon before it will present an install prompt. Both must be PNG or WebP — SVG is not supported in the manifest's icon declarations in current browser implementations.

Each entry in the icons array specifies a src, sizes, type, and optionally a purpose. A well-constructed manifest includes four entries: a 192×192 standard icon, a 192×192 maskable icon, a 512×512 standard icon, and a 512×512 maskable icon. This combination satisfies Chrome's installability criteria while ensuring the app looks polished on both stock Android and custom launchers that employ aggressive icon masking. The manifest also supports a theme_color property that tints the browser's address bar and task switcher entry on Android, creating a more immersive branded experience. This value should match the <meta name="theme-color"> tag in your HTML for consistency between the pre-install browsing experience and the post-install app experience.

SVG Favicons, Theme-Color, and Mask-Icon

SVG favicons represent perhaps the most elegant solution to the multi-size problem. A single vector file scales flawlessly to any resolution, from a 16×16 browser tab to a 512×512 splash screen, without any loss of quality. Declared with <link rel="icon" type="image/svg+xml">, an SVG favicon unlocks a powerful capability that raster formats cannot match: embedded CSS media queries. This means your favicon can respond to the user's color scheme preference, displaying one palette for light mode and another for dark mode. A well-crafted SVG favicon with a prefers-color-scheme query feels remarkably polished, adapting seamlessly as users toggle their system appearance throughout the day.

The limitation is browser coverage. While Chrome, Firefox, and Edge all support SVG favicons, Safari has been slower to adopt them universally, and no mobile platform currently uses SVGs for home screen icons. SVG favicons therefore work best as a progressive enhancement: modern browsers that support them get the benefits of scalability and dark-mode responsiveness, while older browsers fall back to the ICO or PNG versions specified in other link tags.

Safari's pinned-tab icon, declared with <link rel="mask-icon">, is a related but distinct concept. This SVG is rendered as a single-color silhouette in Safari's tab bar, with the fill color specified by a color attribute on the link tag. The SVG must use only black fills and strokes — Safari applies the specified color dynamically at render time. While this feature serves a narrow audience, it adds a layer of visual polish for users who rely on Safari's pinned tabs.

The <meta name="theme-color"> tag rounds out the modern favicon toolkit by controlling the color of the browser chrome itself. On Android, this tints the address bar and status bar to match your brand. Combined with the media attribute, you can specify separate theme colors for light and dark modes, ensuring the browser's UI harmonizes with your site's color scheme regardless of the user's system preference.

A Practical Deployment Workflow

The most efficient path from concept to deployed icons begins with a single high-resolution source image. An SVG master file is ideal because it scales without loss, but a PNG at 1024×1024 or larger serves equally well for raster workflows. From this source, the Favicon Generator produces the complete family of outputs: a multi-resolution ICO file for legacy browsers, an Apple Touch Icon at 180×180, standard and maskable PNGs at 192 and 512 pixels, an SVG favicon for modern browsers, and the corresponding HTML markup and manifest entries.

Deploying these files involves placing the ICO and Apple Touch Icon in the site root where browsers look for them by convention, adding the appropriate <link> and <meta> tags to the document <head>, and ensuring the Web App Manifest references the 192 and 512 icons with correct type and purpose fields. A cache-busting query string on icon URLs — something simple like ?v=2 — is a practical safeguard against aggressive browser caching, which can persist old favicons for weeks even after the underlying file has changed on the server.

Validation should happen on real devices rather than simulators alone. Chrome DevTools' Application panel reveals which icons the browser has discovered and whether they satisfy PWA installability requirements. Testing on an actual iPhone confirms that the Apple Touch Icon renders correctly on the home screen. An Android device with a non-stock launcher verifies that maskable icons hold up within aggressive clipping shapes. These few minutes of cross-device testing prevent the far more embarrassing outcome of discovering, weeks after launch, that your site appears as a generic globe icon on half your users' devices.

The favicon may be small, but it carries outsized importance as the most persistent visual connection between your brand and your audience. Whether a user glimpses your icon in a crowded tab bar or taps it on their phone's home screen every morning, getting it right signals professionalism and attention to detail — and with modern tooling like the Favicon Generator and the Image Resizer, the effort required to do so has never been lower.