A favicon does more than decorate a browser tab: it identifies your site in bookmarks, history, pinned tabs, home screens, app launchers, and some search or sharing interfaces. This favicon size guide explains which dimensions to prepare, when to use PNG, ICO, SVG, or WebP, and how to estimate the smallest practical asset set for a website, progressive web app, or branded web project.
Overview
There is no single favicon size that works equally well everywhere. A small browser tab may display an icon at roughly 16 by 16 pixels, while a device home-screen shortcut or progressive web app can require a much larger source image. The most reliable approach is to create a small family of square assets rather than repeatedly enlarging one tiny file.
Think of the work in three layers:
- Core browser coverage: a 16 by 16, 32 by 32, and 48 by 48 pixel set is a practical baseline for many websites.
- Apple touch icon coverage: a 180 by 180 pixel PNG is commonly prepared for iOS and iPadOS home-screen shortcuts.
- Progressive web app coverage: a manifest commonly includes larger icons such as 192 by 192 and 512 by 512 pixels, with the exact requirements determined by the platform and implementation.
These dimensions are working recommendations, not a guarantee that every browser, operating system, or future platform will behave identically. Always test the exported files in the environments that matter to your audience.
For a broader implementation checklist, see the guide to favicon files, dimensions, and HTML tags. If you are starting with a logo, this favicon creation workflow covers the design decisions before export.
How to estimate the right favicon set
Estimate your asset set by answering three questions: where will the icon appear, which formats can those destinations use, and how much maintenance can your project support?
1. List the destinations
For a conventional website, start with browser tabs, bookmarks, and history. Add an Apple touch icon if visitors may save the site to an iPhone or iPad home screen. Add a web app manifest if the site can be installed or launched as a progressive web app. Pinned tabs on macOS may require a separate monochrome SVG mask icon, depending on your design and browser support goals.
Do not confuse a favicon with an Open Graph image or a social profile avatar. A favicon is a compact site identifier; an Open Graph image is a larger sharing preview; an avatar represents a person, account, or community. The visual system can be related, but the files serve different contexts. The comparison in Open Graph image vs. favicon vs. avatar can help keep those roles separate.
2. Choose the minimum useful dimensions
Use this planning table as a starting point:
| Use case | Suggested dimensions | Typical format |
|---|---|---|
| Small browser display | 16 × 16 | ICO or PNG |
| Standard browser and bookmark display | 32 × 32 | PNG or ICO |
| Larger browser or system context | 48 × 48 | PNG or ICO |
| Apple home-screen shortcut | 180 × 180 | PNG |
| PWA manifest baseline | 192 × 192 | PNG |
| PWA large icon | 512 × 512 | PNG |
| Safari pinned-tab style icon | Vector artwork | SVG mask icon |
These values let you estimate the work before opening a favicon generator or design application. A simple site may need three browser sizes and one touch icon. A site with installation features may need the browser set, touch icon, manifest icons, and a pinned-tab variant.
3. Select formats by function
ICO: useful for legacy and broad browser compatibility, especially when one file contains multiple embedded sizes. If you use ICO, include appropriate small resolutions rather than relying on one enlarged image.
PNG: the practical default for most raster favicon, touch-icon, and manifest use cases. It supports transparency and is straightforward to export and inspect.
SVG: useful for scalable browser icons and monochrome mask-style assets. SVG support and rendering details can vary, so retain a raster fallback where compatibility is important.
WebP: efficient for many web images, but it should not automatically replace PNG or ICO in a favicon package. Use it only when the target browser, framework, and installation context are known to support it as intended.
Inputs and assumptions
A repeatable favicon estimate depends less on the number of files than on the number of contexts you must support. Record these inputs in a project checklist:
- Project type: static site, content site, web application, documentation site, or installable PWA.
- Brand source: logo mark, monogram, wordmark, illustration, or a new geometric symbol.
- Small-size legibility: whether the mark remains recognizable at 16 by 16 pixels.
- Transparency: whether the icon needs a transparent background or a deliberate solid field.
- Platform targets: desktop browsers, mobile home screens, pinned tabs, and installed app surfaces.
- Implementation environment: plain HTML, React, Vite, Next.js, a CMS, or a static hosting platform.
Use the smallest number of variants that meets these inputs. For example, a complex logo may require a simplified favicon mark even if the full logo is used elsewhere. Do not shrink a detailed wordmark until it becomes an unreadable rectangle. At favicon scale, silhouette, contrast, and spacing usually matter more than fine detail.
Also account for safe space. Keep important shapes away from the edge so they remain visible when a platform applies its own rounding, cropping, or background treatment. Export square files, inspect them at actual size, and check both light and dark browser environments when possible.
Worked examples
Example 1: A simple portfolio website
The destination list is limited to browser tabs, bookmarks, and mobile home-screen shortcuts. A reasonable estimate is three small browser assets—16, 32, and 48 pixels—plus a 180-pixel Apple touch icon. You may package the browser sizes in an ICO file and retain PNG versions for explicit HTML links or framework conventions. The design input is a simple monogram with high contrast, so no separate small-size illustration is necessary.
Example 2: A documentation site built with a modern frontend framework
The project needs browser support, responsive deployment, and predictable asset references in a build system. Prepare 16, 32, and 48 pixel browser assets, a 180 pixel touch icon, and confirm the framework's preferred location for static files and metadata. For implementation details, compare the relevant setup guide for React and Vite or Next.js App Router. The estimate is larger in coordination than in image count because paths, cache behavior, and build output must also be checked.
Example 3: An installable progressive web app
Start with the browser set and touch icon, then add at least a 192 by 192 and 512 by 512 PNG for the web app manifest. Test whether the icon remains legible when displayed larger than a browser tab. If the mark includes thin strokes or a transparent edge, create a purpose-built large-icon version rather than assuming the tiny favicon will scale well. Validate the manifest, inspect the generated files, and test installation on the target devices.
When to recalculate
Revisit the favicon plan whenever the identity system, deployment method, or supported platform changes. A redesign is an obvious trigger, but it is not the only one. Recalculate after moving from static hosting to a framework build, adding PWA installation, introducing a custom domain, changing the site's color system, or discovering that an icon is missing in a target browser.
Also review the set when a platform or framework changes its recommended metadata conventions. This is a maintenance task, not a reason to replace working files without testing. Keep a short inventory showing each filename, dimension, format, and consuming tag or manifest entry. That record makes future updates faster and reduces accidental omissions.
For troubleshooting, use the favicon-not-showing checklist, especially before assuming that an incorrect dimension is the cause. Cache headers, file paths, HTML metadata, manifest configuration, and browser history can all affect what you see. If your site uses GitHub Pages, review the GitHub Pages favicon setup guidance for hosting-specific checks.
Practical next step: make a square master artwork, simplify it for 16-pixel legibility, export the browser, touch-icon, and manifest sizes your destination list requires, then test each file at its actual display size. Keep the source artwork and an inventory of dimensions with the project. When the brand or platform changes, update the inventory first and recalculate the smallest complete set rather than exporting every possible size by default.
