August 18, 2026 / Web Design
Favicon design checklist for multiple screen sizes
Favicon design checklist for multiple screen sizes
A tab bar with seven open sites is a brutal test for a small icon. The brand that survives at 16 by 16 pixels, the one that still reads on a 4K display, and the one that looks correct on a phone home screen are usually the result of decisions made before the first pixel is drawn. A favicon design checklist for multiple screen sizes is a way to capture those decisions in one place, so the icon does not only look good on the designer’s laptop, but on every device a visitor might use.
This guide walks through the practical checks that matter when a favicon has to work at 16 px, 32 px, 180 px, and beyond. It focuses on file formats, pixel grids, contrast, dark mode, and the small production habits that prevent a mark from blurring into a colored dot. It also shows how to test the result before pushing to production.
Why a single PNG is no longer enough
Twenty years ago, dropping a 16 by 16 ICO file into the site root was the entire job. Today, the same brand mark can appear in browser tabs, bookmark bars, pinned tabs, mobile home screens, tablet reading lists, search results, and PDF previews. Each surface asks for a different size, a different amount of detail, and sometimes a different background color.
The HTML and platform ecosystems have caught up. The favicon format now includes SVG sources, Apple touch icons, Android Chrome masks, and Safari pinned-tab masks, in addition to the long-standing ICO. Browsers also follow the user’s system theme, so a single light-mode PNG can disappear against a dark tab bar.
The practical consequence is that a favicon is no longer a single file but a small asset package. A clear checklist helps a designer ship every required variant without guessing and without bloating the site with unused sizes.
Core size and format matrix
The table below lists the most common sizes in active use today. It is a working baseline rather than a strict spec, because browsers are free to pick any size they want from a multi-resolution ICO, and some platforms ignore sources entirely.
| Use case | Pixel size | Recommended format | Notes |
|---|---|---|---|
| Classic browser tab | 16×16 | PNG inside ICO | Highest contrast, simplest shape |
| Retina browser tab | 32×32 | PNG inside ICO | Same artwork, cleaner edges |
| Windows taskbar shortcut | 32×32 | PNG | Often read from ICO |
| macOS bookmark bar | 64×64 | PNG | Some browsers use 32 or 64 |
| Apple touch icon (iOS) | 180×180 | PNG | Adds rounded corner mask |
| Apple touch icon (legacy) | 152×152, 120×120 | PNG | For older iOS versions |
| Android home screen | 192×192 | PNG | Chrome picks nearest match |
| Progressive Web App | 512×512 | PNG | Required for install splash |
| Safari pinned tab | Vector | SVG | Single color, no background |
| Modern browser (any size) | Vector | SVG | Browsers rasterize as needed |
| Windows tile (legacy) | 150×150 and wider | PNG | Optional, mostly historical |
The cleanest production setup is a single SVG source for the artwork, a high-resolution PNG master (usually 512×512) for raster fallbacks, and a multi-resolution ICO that bundles the small sizes. From those three files, every other size can be generated consistently.
Step-by-step production workflow
The steps below cover the production side of the favicon design checklist. They assume a designer has already settled on the symbol or mark that will represent the brand.
- Design the mark first at a large scale, ideally 512×512 or higher, on a transparent background. Keep corners and counters honest, not papered over with detail.
- Simplify the mark to a 32×32 grid, then a 16×16 grid, adjusting stroke weights and counter shapes so the silhouette still reads.
- Export the small raster sizes (16, 32, 48) as PNG, then package them into a multi-resolution ICO. Avoid exporting a single 16×16 PNG and asking the ICO encoder to upscale it.
- Export a clean SVG version of the simplified mark. Make sure it uses a single path or a small number of paths, and that the viewBox is set to a square (for example 0 0 64 64).
- Generate the Apple touch icons (180, 152, 120) from the PNG master, leaving a safe margin so iOS rounded corner masking does not crop the mark.
- Create the Safari pinned-tab SVG as a single-color silhouette with fill set to currentColor, so the browser can tint it.
- Add the dark mode variant, either as a media-query SVG or as a separate set of PNGs, so the mark stays legible on dark tab bars.
- Wire everything up with the right link and meta tags, in the correct order, and test the result in real browsers before deploying.
The order matters. The simplified small-size mark is the foundation. The SVG, the ICO, and the platform icons are downstream exports from that foundation. If the foundation is wrong, none of the exports will fix it.
Designing for 16 pixels first
The 16 by 16 tab is the hardest surface a favicon has to survive. At that size, every pixel is a structural decision, and a single soft edge can turn into mush on a low-DPI display. The discipline of designing for 16 pixels first is what separates a favicon that scales up gracefully from one that scales down into a blur.
A useful approach is to draw a 16×16 frame on a pixel grid, place the silhouette of the mark inside it, then thicken or thin it by one pixel at a time until the shape reads at arm’s length on a real monitor. If the mark has internal counters, those should be at least two pixels wide at 16×16, otherwise they fill in and the mark turns into a solid blob.
Type-based favicons deserve extra care. A single letter can work, but only if the letter is drawn rather than set in a system font, and only if the bowl and stroke are heavy enough to survive a 16 px render. If the mark is a wordmark, a custom monogram or initial is usually a better answer.
Pixel grid rules of thumb
- Aim for a silhouette that fills at least 10 of the 16 horizontal pixels, otherwise the mark looks lost in the tab.
- Keep stroke weights to whole pixels at 16×16. Half-pixel strokes blur on most displays.
- Use two-pixel corner radii or no corner radius. One-pixel curves tend to look accidental.
- Avoid gradients at 16×16. Use a single foreground color and, if needed, a single background color block.
- Test the mark on both light and dark tab bars. Pure white or pure black will fail one of the two.
Designing the SVG source
SVG is the most flexible source format for a modern favicon, because a single file can render at any size without resampling. The trade-off is that a sloppy SVG can also look sloppy at every size, since browsers do not apply any smoothing magic the way a careful designer would.
Start the SVG with a clean viewBox, usually 0 0 64 64 or 0 0 100 100, and design inside that frame using whole or half units. Snap curves to a coarse grid so the path data stays readable. Strip metadata, comments, and any invisible layers that tools like Figma or Illustrator leave behind, because they add bytes and can occasionally cause rendering quirks.
If the favicon needs to adapt to the user’s theme, use the prefers-color-scheme media query inside the SVG itself. The same file can carry a light version and a dark version, and the browser will pick the right one based on the active tab color. This avoids the need to ship two separate files and a small block of JavaScript that swaps them at runtime.
SVG hygiene checklist
- Use a square viewBox with whole-number coordinates wherever possible.
- Set width and height to 100 percent, or omit them, so the SVG scales to the host element.
- Avoid external font references; convert any type to outlines.
- Keep the file under a few kilobytes, since it can be requested on every page load.
- If using CSS inside the SVG, keep it inline and simple. External stylesheets are not fetched for favicons.
Dark mode and theme adaptation
Most modern operating systems let users choose between a light theme, a dark theme, and sometimes an automatic setting. Browsers respect that choice in their tab bars and toolbars, which means a favicon designed only for a white background can disappear into a dark tab without warning.
The simplest approach is to ship two SVG sources, one for light mode and one for dark mode, and let the browser pick the right one through the media attribute on the link tag. The light version uses dark colors on a light background, the dark version uses light colors on a dark background, and both share the same underlying silhouette.
For projects that want more control, the SVG itself can carry a media query that swaps colors based on the user’s system theme. The advantage is one file; the disadvantage is that older browsers ignore the query and fall back to the default colors, so the default style still has to be legible in both themes.
| Approach | Files needed | Browser support | Best for |
|---|---|---|---|
| Single SVG, no theme logic | 1 | All | Marks that work on any background |
| Two SVGs with media attribute | 2 | Modern | Marks that need a different background color per theme |
| SVG with internal media query | 1 | Modern | Single-file deployments that still want theme awareness |
| Raster PNGs only | Many | All | Legacy support, sites that cannot ship SVG |
Whatever the approach, the test is the same: open the site in a browser, switch the system theme, and look at the tab bar. If the favicon is harder to find than its neighbors, the design is not done.
Apple touch icons and Android home screens
When a user adds a site to the iOS home screen or installs a Progressive Web App, the system uses a special icon, not the browser tab favicon. The two ecosystems handle this slightly differently, and a complete favicon design checklist for multiple screen sizes covers both.
iOS expects an apple-touch-icon link. The recommended size is 180×180, though older devices still pick up 152×152 and 120×120 if they are present. iOS applies a rounded square mask and, in some versions, drops a subtle gloss effect that can be disabled with apple-touch-icon-precomposed. Designers should leave a safe margin of roughly 10 percent inside the canvas, so the mask does not crop the actual mark.
Android Chrome uses the same set of apple-touch-icon links as a fallback, but for true installability it looks for a 192×192 PNG or a 512×512 PNG referenced through the web app manifest. The manifest also accepts a purpose field that lets the mark be used as a maskable icon, which means the safe area inside the canvas matters even more.
For Safari pinned tabs, the design rules are stricter. The mark must be a single-color silhouette, drawn as an SVG, and fill is set to currentColor so the browser can tint it with the tab bar color. Gradients, multiple colors, and backgrounds are not allowed inside that file.
Wiring it all up in HTML
The asset package is only useful if the HTML actually requests it. The link and meta tags for a modern favicon setup usually include the SVG source, the Apple touch icons, the manifest, and the theme color. The order is not strict, but it helps to group theme-related tags together so future edits stay readable.
A reasonable starting block looks like this, with the SVG first so browsers that prefer it pick it up, then the small raster sizes, then the platform-specific icons, then the manifest and theme color. The exact sizes can be tuned to the platforms the project actually supports.
- Use link rel=”icon” with type=”image/svg+xml” for the scalable source.
- Add link rel=”icon” with type=”image/png” and sizes=”32×32″ for the 32-pixel raster.
- Add link rel=”apple-touch-icon” with sizes=”180×180″ for iOS home screens.
- Reference the web app manifest through link rel=”manifest” for PWA install flows.
- Set meta name=”theme-color” so the browser chrome matches the brand.
The rel=”shortcut icon” attribute is a legacy token that some old parsers still expect. It is harmless to include alongside rel=”icon”, and it can save a few minutes of debugging when an enterprise browser rolls out an update that breaks modern syntax.
Performance and caching
A favicon is requested on every page load, often before the main HTML has even finished parsing, which makes it a small but real lever on perceived performance. The good news is that the file is tiny, and the HTTP cache handles most of the work after the first request.
The bad news is that a multi-resolution ICO can balloon if it bundles every size in the matrix above, including sizes no real device asks for. Trim the ICO to the sizes that actually appear in browsers: 16, 32, and 48 are usually enough. Leave 64 and 128 for sites that want to support high-DPI desktop shortcuts, but do not bundle 256 if nothing asks for it.
SVG files are usually a few hundred bytes, well under the cost of a high-resolution PNG. They are also the right answer for sites that care about the smallest possible payload, because a single SVG replaces several raster files. Cache headers should be set to a long max-age with a fingerprint in the filename, so a new favicon deploy can bust the cache without changing the file path.
Service workers can interfere with favicon caching if they intercept requests for the root path. A common bug is a service worker that responds to every request with the offline page, including favicon requests, which leaves a generic icon in the tab. Excluding favicon paths from the service worker’s fetch handler keeps the real icon visible.
Common mistakes and how to avoid them
Most favicon problems are not creative problems. They are production problems that show up the same way on every project. A short list of the usual suspects helps a designer catch them in review instead of after launch.
- Uploading a 16×16 PNG and letting the browser upscale it for retina displays. Always export the higher-DPI sizes from the same source.
- Forgetting the apple-touch-icon link and wondering why the home screen icon is a screenshot of the page.
- Designing a mark with a thin light-colored stroke on a white background, which disappears on light tab bars and many mobile launchers.
- Shipping only an ICO and not an SVG, which leaves Safari pinned tabs and modern Chrome installs without a sharp source.
- Using background colors inside the SVG that conflict with the browser’s tab color. Either remove the background or use a media query.
- Caching the favicon aggressively after a redesign, so users keep seeing the old mark for weeks. Fingerprint the filename on each deploy.
A pre-launch review that walks through the HTML and checks for each of these will catch the vast majority of favicon bugs. The remainder usually show up in real-world testing, which is the next item on the checklist.
Testing the result in real browsers
The only way to know a favicon works is to see it where users will see it. That means opening the site in at least one desktop browser, one mobile browser, and one platform that pins tabs, and looking at the icon in each surface. Screenshots and design previews are not enough, because the browser’s own scaling and antialiasing can change the result.
A short testing routine covers the critical cases. Open the site in Chrome, Firefox, and Safari, both light and dark mode, and look at the tab bar at standard and high zoom. Open it on an iPhone and an Android phone, and add the page to the home screen to see the touch icon. If the project supports pinned tabs in Safari, pin it and check that the silhouette is visible against the tab bar color.
For web app manifests, a tool like the manifest validator in Chrome DevTools will list any missing sizes and any icon files the browser could not load. This is faster than adding the site to the home screen on multiple devices just to discover a missing 192×192 PNG.
Pre-launch testing checklist
- Tab bar at 100 percent and 125 percent zoom, light and dark themes.
- Bookmark bar icon at default size.
- Home screen icon on iOS, with the rounded mask applied.
- Home screen icon on Android, both standard and maskable.
- Safari pinned tab silhouette in both tab bar colors.
- Search result preview, if the site shows a favicon there.
- PDF export, if the platform includes the favicon in the print header.
Internal links for further reading
Two related guides on this site cover the wider system around the favicon. The piece on visual identity explains how a favicon fits into the larger mark system, and the one on design systems shows how a favicon asset package can live in a shared library.
Frequently asked questions
What is the smallest favicon size I really need to ship?
For most modern projects, a 32×32 PNG inside a multi-resolution ICO is enough to cover 16×16 and 32×32 displays. Add a 48×48 PNG for Windows shortcuts, and you have covered the everyday desktop case. iOS and Android need their own sizes, so 180×180 and 192×192 should ship alongside the ICO.
Should I use SVG or PNG for the favicon?
Use SVG as the primary source if your mark can be drawn as a vector. SVG is sharper at every size, smaller in bytes, and supports theme adaptation through internal media queries. Keep a PNG fallback for older browsers and for the ICO bundle, but treat SVG as the source of truth.
How do I make a favicon work in dark mode?
Design two versions of the mark, one for light backgrounds and one for dark backgrounds, and ship them as separate SVG files. Reference the dark version through a link tag with the media attribute set to prefers-color-scheme: dark, so the browser picks the right one based on the user’s theme.
What is the difference between an ICO and a PNG favicon?
ICO is a container format that can hold several sizes of raster artwork in one file. PNG is a single-image format. Modern browsers accept either, but ICO is still the safest bet for the smallest sizes because it can ship 16×16 and 32×32 in the same request without forcing the browser to pick a single source.
Why does my favicon look blurry on retina screens?
The browser is most likely using the 16×16 entry from the ICO and upscaling it. Ship a 32×32 PNG inside the ICO so high-DPI displays can pick the sharper source, or move to an SVG so the browser can render the mark at any pixel density without resampling.
Do I still need apple-touch-icon in 2026?
Yes. iOS Safari still uses the apple-touch-icon link for the home screen, and it does not fall back to the standard favicon link. A 180×180 PNG is the safe default, and leaving about 10 percent safe margin inside the canvas keeps the mark clear of the rounded mask.
What is a maskable icon, and do I need one?
A maskable icon is a PNG designed to survive the various shapes Android launchers apply to home screen icons, from circles to squircles. The art lives inside a central safe area, with the outer 20 percent of the canvas used as a background that can be safely cropped. If the site is installable as a Progressive Web App, shipping a 512×512 maskable icon is worth the extra export.
How do I test a favicon before pushing to production?
Open the site in Chrome, Firefox, and Safari, in both light and dark mode, and look at the tab bar at 100 percent and 125 percent zoom. Add the page to the home screen on iOS and Android to test the touch icon. Use the manifest validator in Chrome DevTools to confirm the PWA icons are wired up correctly.
Can I use the same favicon for a web app manifest and a regular site?
Yes, with a small caveat. The manifest can reference any PNG, and most projects ship a 192×192 and a 512×512 icon that double as the standard favicon. If you also want a maskable icon, add it as a separate entry in the manifest with purpose set to maskable, so launchers can pick it when they need to apply a shape mask.
What is the safest way to cache a favicon across deploys?
Add a content hash to the filename, like favicon.abc123.svg, and set a long max-age cache header. When the design changes, the new file has a new name, so the browser is forced to fetch it, and the old file can stay in the cache until it expires. Avoid using a query string for cache busting, because some intermediaries strip them.