What manifest.json decides
A web app manifest is a short JSON file that tells Android, Chrome and any WebView that reads it how your site should behave when treated as an app rather than a page. It is what separates a bookmark from something that looks installed.
- Home-screen name and icon —
short_nameandicons. - Whether browser chrome shows —
display;standaloneis what stops a site looking like a web page. - Status bar colour —
theme_color, the highest-impact line in the file. - The launch splash — drawn by Android from
background_color, the icon and the name. - What counts as inside the app —
scope.
display, and the value people get wrong
| Value | The user sees | Use for |
|---|---|---|
standalone | Status bar; no address bar, no tabs | Nearly everything |
fullscreen | No system UI at all | Games, video, kiosks |
minimal-ui | A thin back/reload strip | Content sites where navigation matters |
browser | An ordinary tab | Opting out |
fullscreen tempts and usually disappoints: hiding the clock and battery on a shop or content site annoys people, and on gesture-navigation phones it removes cues users depend on.
Scope traps
scope defines which URLs stay in the app. Set it to /shop/ and a link to /blog/ opens in the browser — sometimes intended, often a surprise. Set it too wide and external links open inside your chrome-less window with no address bar and no obvious way back. Most sites should use / and handle external links in code.
Maskable icons
Android masks home-screen icons to the launcher shape. A regular icon gets letterboxed inside a white circle — the "sticker" look that marks a converted site. An icon with "purpose": "maskable" is drawn edge to edge with the important artwork inside the central 80%. The generated manifest lists both so each platform takes what it wants; the icon set generator produces the padded artwork.
Not AndroidManifest.xml
Despite the name, the two are unrelated. manifest.json is a web standard describing your site; AndroidManifest.xml describes your app — components, permissions, entry points. A converted app has both, duplicating a little information (name, theme colour) in two formats.
For a live-URL app the web manifest still matters: the WebView reads theme_color, and browser visitors get the installable experience. For bundled content it does less — there is no install prompt for a page loaded from disk — but it costs nothing and remains useful on the web.
Where it lives
At the site root, linked from every page's <head>, ideally served as application/manifest+json. Put the theme-color meta tag in the head too — some contexts read it before the manifest has loaded.