← PWA Installability Checker

This checker vs. reading manifest.json by eye

The free way to check installability is to open manifest.json in an editor or a browser tab and read it: is there a name, does display look right, are the icons roughly the expected sizes. That catches the obviously broken cases -- an empty file, a display value that is plainly wrong -- and costs nothing but a minute of attention.

This checker runs the same documented criteria Chrome uses, but does two things a read-through has no easy way to do. First, it actually fetches every icon the manifest lists and confirms each one responds successfully as an image, rather than trusting that a path which looks right in the JSON also resolves on the live site. Second, it resolves every field to its spec default before judging it -- an absent display is not "nothing to check", it is the spec's own default of "browser", which fails the install criteria outright.

Which one answers your question

What you are trying to doWhere to do it
Spot-check a manifest you just hand-wrote for an obviously missing field before committing. Reading it by eye -- fast, and good enough to catch a typo or a blank file.
Confirm every icon a manifest lists actually loads, at the right size, with an image content type -- not just that the path looks plausible. This checker -- it fetches each icon and checks the response, which a read-through of the JSON cannot do at all.
Know whether a manifest with no display field passes or fails, without having to remember the spec's default. This checker -- it resolves the absence to "browser" and reports the fail, the same way Chrome does.
Parse a sizes attribute that lists several tokens on one icon entry and confirm at least one clears 192px. This checker -- it parses every token rather than relying on a glance at the first one.
Check whether the page itself is served over a secure origin, which the manifest file itself says nothing about. This checker -- it checks the page's own scheme, a fact the manifest JSON cannot contain.
Gate a CI run on a manifest regression without opening a file in an editor at all. This checker -- one Node command, a machine-checkable pass/fail.

A quick read of the file is a reasonable first pass while you are still writing the manifest. This checker is what you run before you trust that pass -- it fetches what the manifest points at instead of assuming the paths resolve, and it applies the spec's defaults instead of relying on a reader to recall them.

Common questions

Isn't just opening manifest.json and reading it enough?

For the fields that are obviously wrong on sight -- no name field at all, display set to something that is clearly not standalone -- yes. What a read-through cannot do without extra steps is confirm each listed icon URL actually resolves to a reachable image of the right size, or remember that a missing display field is not neutral: the spec's own default for an absent display is "browser", which Chrome's installability criteria explicitly exclude. A quick read tends to skip past an absent field as "nothing to flag" rather than resolving it to the value it defaults to.

What does eyeballing the manifest miss that this checker catches?

Three things in particular. First, icon reachability: a manifest can list a 192x192 icon path that looks correct in the JSON and still 404, get served with the wrong content type, or point at a build artifact nobody committed -- none of that is visible from the manifest file alone, only from actually fetching it. Second, the sizes attribute can carry several space-separated size tokens on one icon entry ("48x48 96x96 192x192"), and confirming at least one clears the 192px minimum means parsing every token, not just glancing at the first one. Third, the secure-origin requirement depends on how the page itself was served, which manifest.json says nothing about at all.

Why does a missing display field count as a hard fail here?

Because the Web App Manifest spec's own default for an absent "display" is "browser", and Chrome's installability criteria explicitly exclude "browser" from the modes it will install. A human reading the file sees no display key and often reads that as "not set, move on" -- but the browser resolves the absence to a concrete value that fails the check. This tool applies that same resolution automatically instead of relying on the reader to remember the spec's default.

Is anything I paste into either process uploaded?

There is nothing to upload either way. Reading manifest.json in an editor or browser tab involves no third party at all, and this checker's browser page only renders a report from JSON you paste in locally -- the CLI that actually fetches the page, manifest, and icons talks directly to the URL you name, never through this site.

← Back to the PWA Installability Checker