Favicons for a PWA: Do You Actually Need the Manifest Too

Installing a site as an app - the "Add to Home Screen" prompt on a phone, or the install icon in a desktop browser's address bar - needs more than a favicon. It reads from a site.webmanifest file: a small JSON document naming the app, its colors, and which icons to use at which sizes. Skip the manifest and the icon files are still fine for a browser tab; the install prompt either won't appear or will fall back to a generic icon instead of your logo.

What's actually in the generated manifest

The manifest this tool produces references the two largest generated PNGs - 192 and 512 pixels, the sizes Android and Chrome's install flow specifically look for - along with a theme_color, a background_color, and a display mode set to standalone, which is what makes an installed site open in its own window instead of a normal browser tab with address bar and tabs visible. The name and short_name fields ship as placeholders for you to fill in with your actual site or app name - those are specific to your project and can't be generated from an image.

Do you actually need it?

If your site is only ever going to be visited in a normal browser tab, the manifest changes nothing you'd notice - the favicon and Apple touch icon files alone cover the browser tab and iOS home-screen shortcut cases completely on their own. The manifest specifically matters for two things: Android's "Add to Home Screen" install flow, which looks for a manifest before it'll treat a site as installable at all, and any progressive-web-app behavior beyond a static icon (a defined name shown during install, a theme color applied to the browser's UI chrome, standalone display mode). If neither of those applies to your project, it's safe to skip pasting the manifest link and just use the icon files - though there's no real cost to including it either, since an unused manifest on a site nobody installs does nothing but sit there.

Why 192 and 512, specifically

Those two sizes aren't an arbitrary round pair - they're what Android's install flow and Chrome's manifest handling actually request: a smaller icon for the app drawer and launcher-sized contexts, and a larger one for splash screens and higher-density displays where a smaller source would visibly blur when scaled up. Every other size in the full set - 16, 32, 48, 180 - serves a browser-tab or iOS context instead, which is exactly why the manifest only references these two rather than the whole set: it's naming the sizes its own consumers actually ask for, not repeating the full favicon list for no reason.

What still needs a human decision

The generated site.webmanifest is real, valid JSON, ready to reference - but three fields inside it are placeholders by design, because they're facts about your project a generator can't know: the app's actual display name, its short name (used where space is tight, like under a home-screen icon), and a theme color that matches your actual brand rather than a generic default. Open the file, fill those three in, and it's complete. Everything image-derived - the two PNG references, their sizes and types - is already correct and doesn't need touching.

What this tool deliberately leaves out

A few platform-specific icon formats exist and aren't part of the generated set: a Windows pinned-tile icon and its browserconfig.xml, and Safari's pinned-tab SVG. Both were common recommendations several years ago and see very little real use on a modern site today - including them would mean generating and documenting two more file formats for platform features most visitors will never encounter. If a specific project genuinely needs them, they're a manual addition on top of what this tool produces, not a gap in what it covers for everyone else.

Where the theme color actually shows up

On Android specifically, theme_color tints the browser's status bar and, for an installed PWA, the app-switcher card background - a detail easy to miss because it's invisible until someone actually installs the site rather than just visiting it. Matching it to your site's actual accent color, rather than leaving the generated default, is a small thing that makes an installed icon feel like it belongs to your brand rather than a placeholder someone forgot to finish.

Whether or not you end up using the manifest, the icon files themselves - and the manifest, if you keep it - are all built and zipped entirely in your browser. The generator never uploads your source image to produce any of it.

Linking the manifest is a separate step from generating it

The zip includes site.webmanifest as a file, but nothing links to it automatically - that's what the last line of the HTML snippet is for, a <link rel="manifest"> tag pointing at wherever you upload the file. Skip pasting that one line and the manifest sits unused in your site's files, doing nothing, even though it's technically present. It's an easy step to lose track of specifically because it's the only one of the five link tags that doesn't reference an icon file directly.