Skip to main content

Favicon Sizes Explained: 16, 32, 180, 192, and 512 px Done Right

A practical guide to favicon sizes for every platform — browser tabs, iOS apple-touch-icon, Android Chrome, and PWA manifests — with the exact HTML link tags to paste into your head.

Published By 李雷
#favicon #web-development #html #frontend #icons

Favicon Sizes Explained: 16, 32, 180, 192, and 512 px Done Right

The first time I shipped a personal site, the browser tab showed a blank document icon next to the title. I had spent two weeks on the layout and forgotten the one image users stare at every time they open the tab. So I dropped a single 32×32 PNG in the root, called it done, and moved on. A week later an iOS friend pinned the site to their home screen and got a fuzzy screenshot of my header instead of an icon. That tiny square turns out to have rules, and most of them are about size.

This guide walks through the favicon sizes that actually matter in 2026, which platform asks for each one, the exact <link> tags to wire them up, and why PNG has quietly replaced the old .ico container for almost everyone.

Why one size is never enough

A favicon is not a single file anymore. Each surface that renders your icon pulls a different resolution, and if you ship only one, the system downscales (or upscales) it and the result looks soft. A 16-pixel tab favicon and a 512-pixel install icon are two genuinely different design problems: at 16 px you need a bold mark with no fine detail, while at 512 px you have room for gradients and texture. Shipping the same blurry middle size for both fails at both ends.

The good news is that a small, fixed set of sizes covers every real placement. You do not need the 20-icon dumps that some generators produce; you need the handful below.

The sizes that matter, and who asks for each

Here is where each size actually shows up, sourced from the current platform docs and behavior:

  • 16×16 — Standard browser tab and bookmark bar on Chrome, Firefox, and Edge at 1× displays. This is the smallest and least forgiving size.
  • 32×32 — Retina and high-DPI browser tabs, Windows taskbar shortcuts, and the size most browsers prefer when both 16 and 32 are offered.
  • 180×180 — The iOS Safari apple-touch-icon. When a user taps "Add to Home Screen," iOS grabs this file, rounds the corners itself, and applies its own styling. Apple's guidance is to supply a flat, full-bleed square at 180×180, which covers modern iPhones.
  • 192×192 — Android Chrome's standard home-screen icon, declared in the web app manifest (manifest.json). Android reads icons entries from the manifest rather than <link> tags.
  • 512×512 — The large icon Android and the PWA install flow use for the splash screen and high-density launchers, also declared in the manifest. This is the master size most tooling downscales from.

A reliable production set is therefore 16, 32, 180, 192, and 512. The first three live as <link> tags in your <head>; the 192 and 512 sizes live in your web manifest. A favicon set built around these covers browser tabs, iOS pins, Android installs, and PWA splash screens without bloating your markup.

A real input and output: the link tags

Say you generate the icon set for a product called "Toolora" and save the files at your site root. The exact block I paste into <head> looks like this:

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

And the manifest those last two Android sizes need:

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

That is the whole wiring. The single most common failure I see is a filename mismatch: your <link> says apple-touch-icon.png but you saved apple-touch-icon-180.png, so iOS requests a path that 404s and silently falls back to a screenshot. Keep the filenames in your tags identical to what you actually upload, and verify each path returns a 200 before you call it done.

If you want a brand-colored placeholder while you design the real mark, the placeholder image generator gives you a clean stand-in at any size, and you can swap in the final art once it is ready. When you do build the real icon set — text monogram or uploaded logo, all sizes in one pass — the favicon generator outputs the 16, 32, 180, and 512 PNGs with the matching snippet so the references line up on the first try.

.ico versus PNG: pick PNG

The .ico container dates to 1995 and existed because early Internet Explorer would only read favicons in that format. That constraint is gone. Every browser shipping today — including IE 11 in compatibility mode — loads a PNG declared through <link rel="icon" type="image/png">. PNG compresses small icons more efficiently than ICO, supports full alpha transparency, and does not require a special encoder.

There is exactly one case left for .ico: a legacy enterprise stack or an old crawler that hard-codes a request to /favicon.ico at the site root. If you must satisfy that, take your 32×32 PNG and run it through a one-off ICO converter, then drop the result at the root. For the public web, you do not need it, and skipping it keeps your build dependency-free.

Should you add an SVG favicon?

SVG favicons are tempting: one file, perfect scaling, declared with <link rel="icon" type="image/svg+xml" href="/favicon.svg">. Chrome, Firefox, Safari 16+, and Edge all read it. But SVG does not cover the iOS home-screen pin, does not show in some bookmark interfaces, and does nothing for the Android 192/512 manifest icons. So SVG is an enhancement, not a replacement.

The safe pattern is "SVG first, PNG fallback": place the SVG line above your PNG <link> tags, and supporting browsers prefer the vector while everything else falls back to the raster set. The PNG half is still mandatory.

Designing for 16 pixels

Whatever sizes you ship, the icon has to survive at 16×16 in a crowded tab strip. That means a bold, simple mark: a one-to-three-letter monogram, a single shape, or a logo with thick strokes. A full wordmark turns to mush at that scale. If you are generating a text-based icon, pair a strong background with a high-contrast foreground — a quick check against the gradient generator can help you pick a background that stays legible when shrunk. Design the 16 px version first; if it reads there, every larger size will read too.

Get the sizes right, match your filenames, lean on PNG, and your icon shows up crisp in tabs, on home screens, and in install prompts — the small detail users see on every single visit.

Made by Toolora · Updated 2026-06-13