Favicon Size Guide 2026: Every Icon Dimension You Need for Browsers, iPhone, Android, and PWA

Overview

A good favicon is a small asset with outsized impact. It helps users recognize your site in crowded tabs, reinforces brand consistency, and improves the polish of everything from bookmarks to installed web apps. For developers and site owners, the hard part is not designing one icon. It is shipping the right set of favicon dimensions and formats without creating unnecessary file clutter or compatibility problems.

This article is designed as a living reference. Rather than promising a forever-final checklist, it gives you a stable framework you can return to whenever browser behavior, device expectations, or your own brand assets change. The core question is simple: what icon sizes should you generate for your site right now?

In practice, most teams are balancing five icon use cases:

• Browser favicon: the icon shown in tabs and bookmarks
• Legacy compatibility: support for environments that still expect an .ico file
• Apple touch icon: the icon used when a site is saved to an iPhone or iPad home screen
• Android and PWA icons: icons declared in the web app manifest for installable experiences
• High-resolution source asset: a master file you can regenerate from later

The common mistake is either doing too little or too much. Too little means shipping one 32×32 PNG and hoping every device scales it acceptably. Too much means generating a long list of obscure sizes, storing them forever, and making maintenance harder than it needs to be.

For most websites, a useful baseline favicon set includes these dimensions:

• 16×16 for small browser tab contexts
• 32×32 for standard browser favicon usage
• 48×48 as a practical intermediate size for some desktop contexts
• 180×180 for Apple touch icon needs
• 192×192 for Android-style home screen and PWA use
• 512×512 as a large PWA icon and high-resolution application asset

If you want the short version, that set covers the majority of modern use cases cleanly. From there, you can decide whether your project needs extras such as maskable icons, Safari-pinned tab assets, or special CMS-specific conventions.

Format matters too. When people search for a favicon size guide, they are often really asking two questions at once: which dimensions should I create, and which file types should I ship? A practical answer is:

• Use PNG for most raster favicon dimensions
• Use ICO for broad legacy browser support when you want one traditional favicon file
• Use SVG carefully for scalable modern-browser support where appropriate, but do not assume it replaces every raster need

This is why “favicon PNG vs ICO” is not an either-or debate for many teams. The better question is which combination gives you reliable behavior with the least maintenance burden.

How to estimate

You do not need a giant matrix to decide your favicon set. You can estimate what to generate by scoring your site against a few repeatable inputs. Think of it as a lightweight calculator for icon scope.

Step 1: Identify your platform footprint.

Ask where your icon needs to appear:

• Browser tab only
• Bookmarks and desktop shortcuts
• iPhone and iPad home screen
• Android home screen
• Installable PWA
• Pinned or special browser UI contexts

If your answer is only “browser tabs,” your favicon requirements are small. If your answer includes mobile save-to-home-screen and PWA install, your requirements expand quickly.

Step 2: Classify the site into one of three icon sets.

Minimal set: best for simple sites, landing pages, internal tools, and prototypes.

• 16×16 PNG
• 32×32 PNG
• favicon.ico containing common small sizes

Standard set: best for most production websites.

• 16×16 PNG
• 32×32 PNG
• 48×48 PNG
• 180×180 Apple touch icon
• 192×192 PNG
• 512×512 PNG
• favicon.ico

Extended set: best for branded apps, PWAs, design systems, and multi-surface products.

• Everything in the standard set
• Maskable PWA variants
• Optional SVG favicon where supported
• Platform-specific pinned or monochrome variants if your design system needs them

Step 3: Estimate design risk.

Not every logo survives shrinking. Some icons remain legible at 16×16 with no changes. Others need a simplified mark, heavier strokes, or the removal of text. Before generating dozens of sizes, check whether your brand asset passes a simple reduction test:

• Can you recognize it at 16×16?
• Does it still have clear contrast on light and dark browser UI?
• Does it rely on fine detail, thin lines, or small text?
• Does it require padding to avoid feeling cramped?

If the answer to the last two questions is yes, estimate time for a favicon-specific version of the mark. This is often more valuable than producing more dimensions.

Step 4: Estimate implementation complexity.

Count the systems involved:

• Static HTML site
• CMS theme
• React, Vue, or Next.js app
• PWA manifest
• CDN or asset pipeline with aggressive caching

The more layers you have, the more your real task shifts from “how to create a favicon” to “how to deploy and invalidate favicon changes reliably.” For many developers, the hardest part is not generating files but making browsers actually show the updated icon.

Step 5: Choose the smallest set that covers your actual use cases.

This is the calculator mindset. Instead of asking for every possible favicon dimension, estimate the smallest complete kit for your current platform footprint. That keeps your visual brand assets tidy and easier to maintain.

Inputs and assumptions

To make this guide useful over time, it helps to be explicit about the assumptions behind the recommendations.

Assumption 1: You need a master source file larger than any exported favicon.

Create your source asset in vector format if possible, or at least in a large square raster canvas such as 1024×1024. This gives you room to regenerate all smaller files without quality loss. Treat this master as the canonical identity asset, not one of the exported outputs.

Assumption 2: Square icons are the safe default.

Most favicon and app icon workflows assume a square graphic. If your brand mark is horizontal or complex, design a square adaptation rather than forcing the full logo into the icon. A favicon is closer to an avatar than a wordmark; it needs fast recognition more than full brand expression.

Assumption 3: Apple, Android, and PWA contexts do not always use the same file in the same way.

Even when dimensions are similar, platforms may crop, round, scale, or place the icon differently. That is why the article treats apple touch icon size, android favicon size, and PWA icon sizes as related but distinct needs.

Assumption 4: ICO still has practical value.

For teams asking about favicon png vs ico, the practical answer is usually to keep both in the mix. PNG is clean and predictable for named sizes. ICO remains useful because it can bundle smaller variants in a familiar format that many environments still expect by default.

Assumption 5: Caching affects perceived correctness.

You may generate the right favicon dimensions and still think something is broken because the browser, operating system, or CDN is holding an older icon. Any favicon workflow should assume you will occasionally need file renaming, cache busting, or explicit versioning.

Assumption 6: Simpler icons win at small sizes.

If your site icon is doing too much, the fix is rarely more dimensions. The fix is simplification. Use a single shape, monogram, or mark with strong contrast. This is especially relevant for personal brands, open-source tools, and developer products where the favicon often becomes the first visual identifier in tabs and bookmarks.

Recommended baseline dimensions by use case

• 16×16: essential for compact browser UI
• 32×32: standard browser favicon dimension
• 48×48: useful compatibility layer for some desktop and system contexts
• 180×180: safe practical target for Apple touch icon workflows
• 192×192: common target for Android and manifest usage
• 512×512: large-format PWA and installable app representation

Recommended file set for most production sites

• /favicon.ico
• /favicon-16x16.png
• /favicon-32x32.png
• /favicon-48x48.png
• /apple-touch-icon.png at 180×180
• /android-chrome-192x192.png
• /android-chrome-512x512.png
• /site.webmanifest

Sample favicon HTML code

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

Your manifest can then point to the larger Android and PWA icons. The exact manifest structure may vary by framework, but the principle is stable: declare the larger installable assets separately from your browser-tab favicon files.

If you are also working on profile identity assets, the same design discipline applies. The icon that reads cleanly at tiny sizes often also works well as a creator mark or product avatar. For adjacent identity workflows, see How to Create a Professional Avatar for LinkedIn, GitHub, Slack, and Email Profiles and Should You Use a Real Photo, Illustration, or AI Avatar?.

Worked examples

The easiest way to apply a favicon size guide is to map it to real project types.

Example 1: Personal portfolio site

A developer launches a simple portfolio with a home page, project list, and blog. The site is not a PWA, but users may bookmark it or save it to a mobile home screen.

Estimated need: Standard set

• 16×16 and 32×32 for browser tabs
• favicon.ico for broad compatibility
• 180×180 Apple touch icon
• 192×192 and 512×512 in case the site later becomes installable or gets richer manifest support

Why not minimal only? Because the extra large assets add little maintenance burden and keep the site future-friendly.

Design note: Use a monogram or simplified symbol rather than a full-text logo.

Example 2: SaaS dashboard with installable web app goals

A product team maintains a browser app that users keep open all day. Recognition in crowded tabs matters, and there is a clear roadmap toward PWA installation.

Estimated need: Extended set

• Standard browser favicon sizes
• 180×180 Apple touch icon
• 192×192 and 512×512 for manifest
• Maskable icon variants for cleaner installed appearance where supported
• Possibly an SVG favicon for modern environments, tested carefully against fallbacks

Design note: Test the icon in dark and light browser themes. Dashboard products often appear alongside many similar enterprise tabs, so contrast matters more than subtle gradients.

Example 3: Content site on a CMS

A publisher wants a favicon for website use, but does not control every template output directly. The CMS offers a site icon setting, yet some themes add their own markup.

Estimated need: Standard set, with implementation review

• Generate the common dimensions
• Check whether the theme outputs duplicate rel="icon" tags
• Confirm the CMS is not auto-resizing the uploaded master poorly
• Verify the icon after deployment in fresh browser sessions

Design note: Use a centered shape with enough empty space around it. CMS-generated crops can make edge-to-edge art feel cramped.

Example 4: Internal tool or staging environment

An engineering team wants quick identification for multiple environments: production, staging, demo, and local dev.

Estimated need: Minimal set for each environment, but with visual differentiation

• 16×16 and 32×32 PNG
• favicon.ico
• Optional color-coded or badge-based variants per environment

Design note: Favor clarity over brand purity. A tiny environment badge can prevent costly mistakes when multiple tabs are open.

For teams building a broader identity system, it can help to align favicon logic with other visual assets such as avatars, creator marks, and profile icons. Related reading: AI Avatar Generator Comparison and Best AI Avatar Generators Compared.

When to recalculate

The most useful favicon guides are the ones you return to, not the ones you read once. Recalculate your icon set when any of these changes happen:

• Your logo changes: especially if the new mark has thinner detail, more text, or a different shape
• Your site becomes installable: adding a manifest or PWA support changes your icon requirements
• You add iPhone or Android home-screen usage to your product goals: this raises the importance of touch and manifest icons
• Your framework or CMS changes its asset pipeline: file naming, build output, and caching behavior may shift
• You notice visual inconsistency across devices: fuzzy scaling, cropping, or poor contrast is a signal to regenerate
• You restructure caching or CDN rules: favicon updates often fail silently if caching is not reviewed
• Platform conventions evolve: this is why a living reference matters

Here is a practical maintenance checklist you can use each time:

1. Open the master icon file and confirm it is still the approved brand mark.
2. Review whether the icon is legible at 16×16 and 32×32.
3. Export the current baseline set: 16, 32, 48, 180, 192, and 512.
4. Rebuild favicon.ico from the current small-size assets.
5. Check your HTML head tags and manifest declarations.
6. Version or rename files if your cache strategy is aggressive.
7. Test in at least one desktop browser, one iPhone context, and one Android or PWA context if relevant.
8. Store the source asset and exported files in a predictable location in your repository.

If you want the most future-proof default for 2026, use this decision rule:

Minimal site? Ship 16×16, 32×32, and favicon.ico.
Typical production site? Add 48×48, 180×180, 192×192, and 512×512.
PWA or app-like product? Add manifest-specific and maskable variants, then test installation flows.

That approach keeps your favicon dimensions lean, your implementation understandable, and your visual brand assets ready for the places users actually see them.

One final note: favicon work is part of digital identity, not just front-end housekeeping. The same care you put into a site icon should carry into your broader personal or product identity system. If you are refining the rest of that system, our guides on professional avatars and avatar style choices are useful next steps.