How to Make a Favicon That Looks Sharp at 16x16

The favicon is the small icon that appears in a browser tab. It also shows up in bookmarks, search history, the address bar on mobile, and the home screen when someone installs your site as an app. It is one of the smallest pieces of brand work most teams ever ship, and it is also the one that most reliably looks bad.

Here is the version of this post I wish I had read three years ago. A favicon is not a small version of your logo. It is its own piece of design work, constrained by the math of pixel grids. Treating it as a thumbnail of a larger asset is why most favicons look like a smudge in the tab.

This post walks through what actually happens when a browser renders a favicon, what sizes you should ship, and the design constraints that make a small icon either crisp or fuzzy.

What the browser actually does with your favicon

When a tab loads, the browser asks the page for an icon and renders it inside the favicon slot. On most desktop browsers that slot is 16 by 16 pixels. On a Retina or HiDPI screen the 16 logical pixels are rendered using 32 or 48 physical pixels, depending on the device pixel ratio.

The browser picks the icon it thinks fits best from whatever the page advertises. If you ship a single 512 by 512 PNG and tell the browser to use it, the browser scales it down to fit the tab slot. Scaling a 512 pixel image down to 16 pixels is lossy. The algorithm browsers use is not the same algorithm a design tool would use, and the result is usually softer than the same icon designed at 16 by 16 directly.

That is why a favicon that looks crisp in your design tool can look fuzzy in a real browser tab.

The sizes you actually need to ship

There is a small set of sizes that covers the vast majority of real contexts:

• 16x16 PNG, for the standard desktop browser tab
• 32x32 PNG, for retina tabs and many bookmark surfaces
• 180x180 Apple touch icon, for iOS home screen bookmarks
• 192x192 and 512x512 PNGs, for the PWA manifest
• A multi-resolution favicon.ico containing 16x16 and 32x32 frames, for older browsers and tools that prefer ICO

Some sites also ship 48x48, 96x96, and various Android adaptive sizes. The first five are the high-leverage ones.

You do not need every one of these as a literal hand-tuned design. But you do need at least the 16 and the 32 designed for their own pixel grids. The rest can scale down from a 512 source without much pain.

Why the 16x16 is the hard one

Sixteen by sixteen is 256 pixels. That is the entire canvas for the design. Compare that to a 200 by 200 logo, which gives you 40,000 pixels to work with. The 16x16 has less than one percent of the resolution.

The practical implications:

• One pixel of stroke width is six percent of the image height. Three pixel strokes are common at this size, and they look chunky.
• Text is usually impossible. A capital R needs roughly seven pixels of height to be legible. Lowercase needs more. You have sixteen pixels total, and you need padding on top and bottom.
• Anti-aliasing has nowhere to go. A diagonal line at 16 pixels gets rendered with gray pixels along the edge. Those gray pixels are a significant portion of the total image area.
• Color subtleties get lost. Gradients compress into visible bands. Subtle drop shadows become a blurry halo.

The design rule that follows: a favicon should be readable as a silhouette. If you cannot tell what the icon is from the rough shape alone, it is too detailed for this size.

Designing for the pixel grid

The reliable approach is to design the 16x16 first, not last. Open a 16 by 16 canvas in a tool that lets you see individual pixels, and draw the icon at that size. Then size it up to 32 and adjust where the larger grid lets you add detail. Then build the 180, 192, and 512 versions on top.

A few specific tactics:

• Use the pixel grid. Snap edges to whole pixels. A line that falls on a sub-pixel boundary will be anti-aliased into a soft gray band.
• Pick a single dominant shape. A bold geometric form reads at small sizes better than a detailed mark. Look at the favicons of Figma, GitHub, or Notion. Each is a single recognizable silhouette.
• Avoid thin strokes. A two pixel stroke is the practical minimum for legibility at 16x16. Most logos with hairline strokes need a different mark for their favicon.
• Limit the color count. Two or three colors is usually enough. More than that and the icon reads as a smudge of color rather than a shape.
• Skip the gradient. Gradients need enough pixels to render the color transition. At 16x16 there are not enough pixels.

If your brand logo is intricate, accept that the favicon will be a different mark. Pinterest's full wordmark is the word Pinterest. Its favicon is just a white P inside the red circle. That is normal and correct.

The ICO format and why it still matters

PNG favicons cover most modern browsers, but the ICO format has a property no other format has. It can hold multiple resolutions in a single file. A .ico can contain a hand-tuned 16x16 frame and a hand-tuned 32x32 frame, and the browser picks the right one for the surface that is rendering it.

Modern browsers can also pick the right PNG if you give them multiple <link rel="icon"> tags with explicit sizes. So in practice you can use either approach. The ICO approach has one practical advantage: when older code, link previewers, feed readers, or RSS clients look for a favicon at the conventional /favicon.ico path, you can serve a real multi-frame ICO and have every size work without extra markup.

The downside of ICO is that no mainstream design tool exports it directly. You either build the file manually with a converter, or you use a tool that does the multi-resolution packing for you.

Common mistakes

A few patterns I see repeatedly when auditing favicons:

1. Shipping only a 512x512 PNG. The browser scales it down poorly. The favicon ends up softer than it should be.
2. Designing at 1024 and scaling. Same problem in reverse. The 16x16 you get from a 1024 source has no input from a human about which pixels matter most.
3. Using brand colors that disappear on dark mode tabs. Browsers do not automatically invert favicons for dark theme. A dark gray logo on a transparent background can vanish in a dark tab strip. If your mark is dark, consider giving it a colored background or a light fill.
4. Forgetting the apple-touch-icon. When a user adds your site to their iOS home screen, iOS uses the apple-touch-icon at 180x180. If you only ship 32x32 PNGs, iOS substitutes a screenshot of your page, which is almost always worse than even a mediocre branded icon.
5. Skipping the PWA manifest icons. If you have a manifest.json and it references icons that do not exist, Chrome warns about it in DevTools, and users who install the site get a generic icon.

A practical workflow

The least-painful flow I have found:

1. Sketch the icon at 16x16 first, on a real pixel grid. Iterate until the silhouette is clear.
2. Build the 32x32 version, adjusting strokes and details for the larger grid.
3. Build a 512x512 master, refining detail that only appears at large sizes.
4. Export PNGs for 16, 32, 48, 96, 180, 192, and 512.
5. Pack the 16 and 32 PNGs into a multi-frame ICO.
6. Link each PNG with an explicit <link rel="icon" sizes="..."> in your HTML head, and put the ICO at /favicon.ico for the conventional path.

If you want to skip the pixel-pushing and the ICO packing, the Favicon Generator on this site builds the full pack from a single source image, or just initials, runs entirely in your browser, and outputs the multi-frame ICO plus the PNGs in the sizes browsers expect.

What about SVG favicons

Browsers have been adding support for SVG favicons. Chrome, Firefox, Safari, and Edge can all render <link rel="icon" type="image/svg+xml">. The SVG path is appealing because a single vector file scales perfectly.

The catch is that browsers still rasterize the SVG to render it in the tab. That rasterization happens at whatever size the tab needs. If your SVG has thin strokes or fine detail, the rasterized output at 16x16 looks the same as a poorly-scaled PNG. SVG is not a magic fix for the pixel grid problem. It just moves the rasterization step from your build pipeline to the browser.

The practical recommendation: ship an SVG favicon as a progressive enhancement, and a hand-tuned ICO with 16 and 32 frames as the fallback for browsers and contexts that prefer raster.

The summary

A favicon is small enough that the design is constrained by individual pixels. Designing it at full size and shrinking is the most common reason favicons look bad. Sketch the 16x16 first, on the pixel grid, and build the larger sizes on top. Ship at minimum a multi-frame ICO plus PNG sizes for 16, 32, 180, 192, and 512, and link them explicitly in your HTML head.

If the icon reads clearly as a silhouette at 16 by 16, the rest follows.