The favicon and PWA icon sizes you actually need in 2026

If you have shipped more than a handful of sites, you have probably dropped a single favicon.ico in the root and moved on. That used to be almost enough. In 2026 it is not.

Browser tabs, search results, iOS home-screen shortcuts, and Android install surfaces all want different files, sizes, and compositions. Missing one of them rarely breaks the page. It just means a blurry tab icon, a cropped launcher mark, or a generic globe where your brand should be.

I built favicon.now because I was tired of assembling that package by hand, and I am the site's maker, so I will be explicit about that. Here is the checklist: the files that matter, the HTML and manifest, and the mistakes I still see.

The practical set in 2026

You do not need twenty icon sizes — just a small set that covers tabs, search, Apple shortcuts, and installable web apps.

favicon.svg. The modern tab icon. A self-contained SVG stays sharp at any density and can adapt to light and dark chrome when the artwork is designed for it. Pair it with a raster fallback; not every older client will use the SVG.

favicon.ico. Still the compatibility file. Browsers and some legacy clients look for it at the site root even when you forget a <link> tag. A real ICO is a container with multiple frames, not a renamed PNG. At minimum, include solid 16×16 and 32×32 coverage.

favicon-48x48.png. An explicit square PNG for browser and search contexts. Search engines that display a favicon generally want a square image whose size is a multiple of 48 pixels.

apple-touch-icon.png (180×180). The icon iOS uses when someone adds your site to the home screen. Keep it square, give it an opaque background that suits the mark, and do not bake rounded corners into the image.

icon-192x192.png and icon-512x512.png. The baseline PWA icons. 192 is the compact Android and installed-app size; 512 is the large source for install UI and splash surfaces. These are ordinary any-purpose icons, so they can keep transparent edges if that is how the mark is designed.

maskable-icon-192x192.png and maskable-icon-512x512.png. Separate files for adaptive Android shapes. A maskable icon lets the OS crop it into a circle, rounded square, or squircle. Keep essential artwork inside a central safe zone and fill the canvas with a full-bleed background. Relabeling a transparent tab icon as purpose: maskable does not change the pixels, and the crop will look wrong.

site.webmanifest. JSON that declares the app name, colors, icon paths, sizes, and purposes. Relative icon paths resolve against the manifest URL, not the page URL.

Extra PNGs at 16, 32, and 96 pixels are useful fallbacks, but optional once this set is in place.

The HTML to put in your document head

Upload the files to a stable public directory, usually the site root, then add these tags to the shared layout. Root-relative paths keep nested pages consistent.

<link rel="icon" href="/favicon.svg" type="image/svg+xml" sizes="any">
<link rel="icon" href="/favicon-48x48.png" type="image/png" sizes="48x48">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="apple-touch-icon" href="/apple-touch-icon.png" sizes="180x180">
<link rel="manifest" href="/site.webmanifest">

Put the SVG first for browsers that can use it, then the PNG and ICO as fallbacks. The Apple touch icon uses its own rel. The manifest is how install surfaces discover the 192 and 512 assets.

A manifest snippet that tells the truth about purposes

A minimal, honest site.webmanifest looks like this:

{
  "name": "My Website",
  "short_name": "My Website",
  "start_url": "/",
  "scope": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0f172a",
  "icons": [
    {
      "src": "/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "any"
    },
    {
      "src": "/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    },
    {
      "src": "/maskable-icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "maskable"
    },
    {
      "src": "/maskable-icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ]
}

Replace the name and colors with your own. Use standalone only if the site is designed as an installed app; browser or minimal-ui is safer for a content site. A valid manifest does not make a site installable by itself. HTTPS, a service worker in some browsers, and each browser's own heuristics still apply.

Common mistakes

Judging the mark only on a large canvas. A logo that looks perfect at 512 pixels can collapse into a smudge at 16. One or two letters, a simple silhouette, and open padding survive; a full wordmark usually does not.

Renaming a PNG to favicon.ico. That does not produce an ICO. The container and its frames have to be written as ICO.

Skipping a square crop, or baking iOS rounded corners into the Apple touch icon. Tabs and home screens are square. If the important part of the mark is off-center or tight against the edge, it will get clipped. Leave corner rounding to the device.

Declaring a transparent icon as maskable. Adaptive launchers will crop the corners and expose whatever sits behind the icon, often as a letterboxed mess.

Forgetting light and dark browser chrome. A white mark on a transparent background disappears on a light tab bar; a black mark disappears on a dark one. If you use transparency, check both.

Pointing the manifest at the wrong path. Relative src values resolve from the manifest's URL. If site.webmanifest lives in /assets/, icon-192x192.png is requested from /assets/icon-192x192.png unless you use a root-relative path.

Treating the favicon as an SEO ranking lever. It is not a direct ranking factor. A valid, recognizable icon can improve how your result is presented when a search engine chooses to show it.

Checking only the template source. Confirm the rendered document head, then open each icon URL and the manifest directly. Look for HTTP 200, the right format, and the declared dimensions — caches can keep serving an old ICO after you replace the file.

How I generate the package

favicon.now is a free generator I built to produce that same documented set from one source. You can start from an image (PNG, JPG, SVG, WebP, BMP, or GIF), an SVG you want to keep as a vector, one or two letters, or an emoji.

The editor runs in your browser. You adjust spacing, colors, and shape, and you can inspect the mark at 16, 32, 48, 180, 192, and 512 pixels, plus mockups of tabs, search results, and phone home screens. A maskable preview shows the safe zone so letters and symbols stay inside the inner guide.

The download is one ZIP. The standard package is 14 documented files: favicon.svg, a six-frame favicon.ico (sizes from 16 through 256 pixels), browser PNGs at 16, 32, 48, and 96, the 180×180 Apple touch icon, ordinary and maskable 192 and 512 PWA icons, plus site.webmanifest and the HTML to paste into your layout.

Editing and previews stay in the browser. A ZIP request sends the final square image — and a sanitized SVG when you supplied one — to an in-memory packaging endpoint. That request is not intentionally stored. A project is saved only if you sign in and choose to keep it on a profile.

Ship the right sizes once, wire them up correctly, and you can stop thinking about it.