Favicon Formats and Sizes: What You Actually Need in 2025

Favicon setup has accumulated a decade of cargo-culted advice — generators that output sixteen files and a bloated manifest for a static blog. Most of that is unnecessary in 2025. Here's what's actually load-bearing versus dead weight, broken down by what each browser or OS surface genuinely requests.

The Minimum That Covers Everything

For the vast majority of sites — not building an installable PWA, just wanting a correct icon everywhere — this covers it:

<link rel="icon" href="/favicon.ico" sizes="32x32" />
<link rel="icon" type="image/svg+xml" href="/icon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />

Three files. That's the whole surface area for a non-PWA site. Everything past this point is for specific additional use cases — home screen installs, PWA manifests, or supporting truly ancient browsers — and should be added deliberately, not by default.

Format-by-Format Breakdown

favicon.ico — Still the Universal Fallback

.ico is a legacy container format that can bundle multiple bitmap sizes in one file, historically 16×16, 32×32, and 48×48. Browsers request /favicon.ico automatically even with no <link> tag present, which is why it's worth keeping regardless of what else you configure — it's the implicit fallback path baked into browser behavior for decades. A single 32×32 PNG re-encoded as .ico is sufficient; you don't need to hand-craft a multi-resolution .ico unless you're specifically targeting old Windows shortcut icon rendering.

SVG — The Modern Default

<link rel="icon" type="image/svg+xml"> is supported in current Chromium and Firefox browsers per caniuse and is the best format for a site with a simple logomark, since one file scales losslessly to every size a browser tab, bookmark, or history entry needs. It also enables a trick no bitmap format can do — a favicon that adapts to system dark mode using an embedded media query:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
  <style>
    path { fill: #111; }
    @media (prefers-color-scheme: dark) {
      path { fill: #eee; }
    }
  </style>
  <path d="M4 4h24v24H4z" />
</svg>

Run it through the SVG Optimizer before deploying — favicon SVGs are requested on every single page load, so stripped editor metadata and redundant path data matter here more than almost anywhere else on the site.

Safari's support for SVG favicons has historically lagged, which is exactly why the SVG tag ships alongside .ico and apple-touch-icon, not instead of them.

PNG — For apple-touch-icon and Broader Coverage

Apple's Human Interface guidance is to provide a dedicated apple-touch-icon, sized 180×180px, as a PNG (no transparency — iOS renders it against its own home screen background and applies its own corner-rounding mask, so a transparent PNG doesn't look intentional here):

<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png" />

If you support home screen installs on Android too, or want an installable PWA, add a manifest.json with an icon set instead of stacking more <link> tags — that's the correct extension point, covered next.

Decision Point: Do You Need a Full PWA Icon Set?

Skip the full manifest icon matrix (192×192, 512×512, maskable variants) unless your site is actually installable — meaning it has a service worker and you want the "Add to Home Screen" / "Install App" prompt to work well on Android and desktop Chrome. If that's not a goal, a manifest with a single reasonable icon reference or no manifest at all is fine; generating the full spread for a static blog or marketing site is pure overhead with no user-facing benefit.

If you do need it, per the Web App Manifest icon spec, the two sizes that matter most are 192×192 and 512×512, plus a maskable purpose variant if you want the icon to survive Android's adaptive icon masking without important content getting clipped at the edges:

{
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" },
    { "src": "/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

A maskable icon needs extra padding — keep the important content inside roughly the center 80% of the canvas, since Android's mask can crop up to the outer edge depending on device shape.

Generating the Files

Design at a large size — 512×512 or an SVG source — and downscale, never the reverse. Upscaling a small source favicon produces visible softness at larger install-icon sizes. The Image Resizer handles the PNG exports at each required dimension from one master file, keeping every size consistent instead of hand-exporting each one separately and risking drift between them.

Favicon Caching Is More Aggressive Than You Expect

Browsers cache favicon.ico unusually persistently — often independent of the normal HTTP cache headers your server sends, and sometimes tied to browser profile data rather than the page cache at all. This means a favicon update can fail to show up for returning visitors for days, even after a hard refresh, while showing correctly in incognito or on a fresh profile. Two things help: serve .ico and other icon files with explicit Cache-Control headers so at least the intended lifetime is correct, and if you need to force a visible update, change the filename or add a version query string (/favicon.ico?v=2) rather than relying on cache invalidation to catch it. For the SVG and PNG icons referenced via <link> tags, this is less of an issue since you control the URL and can cache-bust it like any other asset — it's specifically the implicit /favicon.ico fallback path that browsers treat unusually.

Verifying Your Setup Actually Works

Don't assume the <link> tags are correct just because they're present — test the actual rendered result:

• Open the site in a private/incognito window (bypasses favicon caching) and check the browser tab.
• Bookmark the page and check the bookmark icon, which sometimes pulls from a different source than the tab icon depending on browser.
• On iOS Safari, use "Add to Home Screen" and confirm the apple-touch-icon renders correctly rather than a screenshot of the page — this is the most commonly broken surface since it's the easiest one to forget testing.
• If you added a manifest, use your browser's DevTools Application/Manifest panel to confirm the icons resolve and the JSON parses without errors — a malformed manifest fails silently in most browsers rather than throwing a visible error.

A favicon that "looks right" in the browser tab during development doesn't guarantee the apple-touch-icon or manifest icons are correctly wired, since those only render on surfaces (home screen install, PWA install prompt) that a normal dev workflow doesn't naturally exercise.

What to Skip

• Multiple .ico resolutions bundled in one file — a single 32×32 PNG-as-ICO covers current browser behavior; the old 16/32/48 multi-res bundling was for pre-retina Windows icon rendering.
• msapplication-* meta tags for Windows tiles — this was for pinned-tile Start Menu integration on Windows 8/10 and is dead weight on a modern site.
• A dozen numbered PNG favicon sizes (16, 24, 32, 48, 64, 96, 128, 180, 192, 512...) generated "just in case" — cover the handful of surfaces above and stop; extra sizes add build output and cache-busting overhead with no browser actually requesting them.

Three files and, only if you need installability, one manifest with two or three icon entries — that's the complete, current favicon setup. Anything beyond that should map to a specific surface you've confirmed actually requests it.