Do PWAs actually work offline?

Why installable does not mean offline

Chrome's installability check asks for a manifest, icons, a display mode and a service worker with a fetch handler. It does not ask whether that worker stores anything. A worker that registers, activates, and caches nothing satisfies every condition — and produces an app that installs perfectly then opens blank.

That gap is the whole reason the two numbers differ. All 386 apps we measured are installable; 151 are usable offline. Nothing in the install prompt distinguishes them, which is why users learn the difference the hard way.

The three degrees of offline

**The shell only.** The app frame appears — header, navigation, maybe a spinner — and the content never arrives, because the API is excluded from caching. Common, reasonable as a default, and disastrous for anything used in the field. We measured one grocery-list app whose author built it to tick items off in a supermarket aisle; the shell cached, the list did not.

**Shell plus data.** The app opens with your last known content. This is what most people mean by offline, and it needs a deliberate caching strategy for GET responses, not just the app files.

**Full local-first.** The app writes offline and reconciles later. This is the hardest, because it is no longer a caching problem but a merge problem — two people editing the same thing with no connection between them.

How to know before you rely on it

Install the app, turn on airplane mode, and open it. That is the only test that matters and it takes fifteen seconds. Everything else — audits, badges, claims in a listing — is a proxy for this.

Every listing in this directory records the result of exactly that test, with the date. When we write that an app works offline, it means we loaded it, cut the network, and it still worked. You can have the same run on your own app.

Frequently asked