Tech Stack Guides

How to Tell if a Website Uses Progressive Web App (PWA) Features

A web app manifest, a registered service worker, installability and a theme-color tag are the PWA signals. Here is how to detect them in Chrome DevTools.

StackOptic Research Team13 May 202610 min read
Detecting Progressive Web App (PWA) features on a website

To tell if a website uses Progressive Web App (PWA) features, open Chrome DevTools and go to the Application tab: the Manifest pane shows whether the site has a web app manifest, and the Service Workers pane shows whether one is registered and active. Those two — a valid manifest (linked via <link rel="manifest">) and a registered service worker, served over HTTPS — are the defining PWA features. A quick View Source also surfaces the manifest link and a theme-color meta tag. The practical confirmation is installability: when the building blocks are correctly in place, Chrome offers an install option in the address bar. This guide covers every signal, how to read them in DevTools and Lighthouse, and how to distinguish a true PWA from a site that merely has a few of the pieces.

It fits the broader how to find out what technology a website uses and connects to performance work in how to make your website load faster, since service-worker caching is as much a speed technique as a PWA feature.

What a PWA is, and what to look for

A Progressive Web App is a website built to behave like an installed app: it can be added to the home screen or desktop, launch in its own window without browser chrome, work offline or on flaky connections, and (with permission) receive push notifications. There is no single "PWA flag" — instead, a PWA is defined by a combination of building blocks, and detecting one means confirming those blocks are present. The two that matter most are a web app manifest (which tells the browser how to present the installed app) and a service worker (a background script that enables offline support and caching), all served over HTTPS (a hard requirement). Supporting signals — a theme-color, app icons — round out the app-like experience. Because all of these are observable in the browser, identifying PWA features is straightforward in Chrome DevTools.

Signal 1: the web app manifest

The first defining signal is the web app manifest. The page links to it in the <head>:

<link rel="manifest" href="/manifest.json">

(The file is sometimes named manifest.webmanifest.) The manifest is a small JSON document describing the installed-app experience: its name and short_name, an icons array, a start_url, a display mode (standalone, fullscreen, minimal-ui or browser), and theme_color and background_color. To read it, open Chrome DevTools (F12), go to the Application tab, and select Manifest in the sidebar — DevTools parses the file and shows the name, icons, start URL and display mode in a readable panel, flagging any problems. A valid manifest with a standalone (or fullscreen) display mode and proper icons is a strong PWA signal: it means the site is set up to be installed and launched as an app.

Signal 2: a registered service worker

The second defining signal — and the one that separates a real PWA from a site with a manifest bolted on — is a registered service worker. A service worker is a JavaScript file that the browser runs in the background, separate from the page, and it is what enables offline support, request caching, background sync and push notifications. To check, stay in the Application tab and select Service Workers in the sidebar. If one is registered you will see its script URL, its status (you want "activated and is running"), and controls to update or unregister it. You can also confirm from the Console by running navigator.serviceWorker.getRegistrations(), which lists any registrations and their scopes. A service worker that is registered and active is the engine of a PWA's app-like behaviour; without one, a site cannot be installed as a PWA or work offline.

Signal 3: installability

The practical, combined test is installability. Chrome's baseline criteria are well defined: the site must be served over HTTPS, expose a valid manifest with the required fields (name/short_name, icons, start_url and a display mode), and register a service worker. When all of that is satisfied, Chrome surfaces an install affordance — an install icon in the address bar (desktop) or an "Install app" / "Add to Home screen" item in the menu (mobile). Seeing that install option is the clearest single confirmation that you are looking at a genuine, correctly configured PWA, because the browser only offers it when the pieces fit together. If the manifest is present but there is no install option, something is missing — usually the service worker or a required manifest field.

Signal 4: theme-color and app icons

Two supporting signals round out the picture. A theme-color meta tag in the <head>

<meta name="theme-color" content="#0b1220">

— tells the browser what colour to tint its UI (the address bar on mobile, the title bar of an installed window), giving an app-like feel. An apple-touch-icon link provides the home-screen icon for iOS. These are easy to spot in View Source and indicate a site has thought about the installed and mobile experience. On their own they are not sufficient — plenty of ordinary sites set a theme-color without being PWAs — but alongside a manifest and service worker they corroborate a deliberate app-like build.

The signal table

SignalWhere to checkWhat it means
<link rel="manifest"> + manifest.jsonView Source; Application → ManifestWeb app manifest present — core PWA signal
Registered service workerApplication → Service Workers; ConsoleOffline/caching engine — core PWA signal
Install option in address bar/menuChrome UISite meets installability criteria — confirms a real PWA
Served over HTTPSAddress bar; headersHard requirement for service workers and install
theme-color meta tagView Source; ElementsApp-like UI tinting — supporting signal
apple-touch-icon linkView SourceHome-screen icon for iOS — supporting signal

Read the combination: a manifest plus a registered service worker over HTTPS is the set that defines an installable PWA.

Method 1: the Chrome DevTools Application tab

The primary tool is Chrome's Application tab, because it gathers every PWA building block in one place. Open DevTools (F12), go to Application, and work down the sidebar: Manifest parses and displays the web app manifest (and warns about missing fields); Service Workers shows registration and status; and Storage sections (Cache Storage, IndexedDB) reveal what the service worker is caching for offline use. This single tab answers "does this site have a manifest?", "is a service worker running?" and "what is it caching?" — the three questions at the heart of PWA detection. It is the most direct method and the one to reach for first, the same Application-tab workflow used to inspect cookies and storage across technology detection.

Method 2: View Source and the Console

For a fast first pass, View Source (Ctrl/Cmd + U) and search for manifest, theme-color and serviceworker (or sw.js). You will quickly find the <link rel="manifest">, the theme-color meta tag, and often the inline script that registers the service worker (a call to navigator.serviceWorker.register(...)). Then confirm in the Console with navigator.serviceWorker.getRegistrations() to see live registrations, and fetch the manifest URL directly in a new tab to read its raw JSON. This source-and-Console combination is quick and works in any Chromium browser, and it cross-checks what the Application tab shows in a more visual form.

Method 3: the Lighthouse PWA audit

For a structured verdict, run Lighthouse, built into Chrome DevTools under the Lighthouse tab (it also powers PageSpeed Insights). Lighthouse has historically included PWA checks that test exactly the criteria above — a valid manifest with the required fields, a registered service worker, HTTPS, a suitable viewport and a theme-color, and whether the page is installable — and reports pass/fail for each with explanations. Note that the PWA category in Lighthouse has changed over versions and may appear as a dedicated section or be folded into the installability and best-practices checks depending on your Chrome version, so treat the exact layout as version-dependent. Either way, Lighthouse is the most thorough single check, because it actively validates the building blocks rather than just confirming they exist — it tells you not only that a manifest is present but whether it is complete enough to be installable.

A worked example

You want to know whether a web app is a real PWA. You open it in Chrome over HTTPS and go straight to the Application tab. Under Manifest, DevTools shows a parsed manifest: a name, a full icons array including a 512px icon, a start_url of /, and display: standalone — a complete, install-ready manifest. Under Service Workers, a worker is registered from /sw.js and its status reads "activated and is running"; the Cache Storage section lists precached assets, so it caches for offline use. Sure enough, Chrome shows an install icon in the address bar. To be thorough, you run the Lighthouse audit, which confirms the installability checks pass. The verdict is clear: this is a genuine, installable PWA with offline caching — not just a site that linked a manifest. By contrast, a different site you check has a manifest.json and a theme-color but no service worker and no install option, so it has merely adopted some PWA polish without being installable. Reading the combination, not a single tag, is what distinguishes the two.

What detection can and cannot see

Detection reliably shows whether the PWA building blocks are present and valid: the manifest and its contents, whether a service worker is registered and active, what it caches, and whether the site is installable — all observable in DevTools and Lighthouse. What it does not tell you is how well the offline experience actually works in every scenario, the full logic inside the service worker (you can read its script, but its caching strategy and behaviour under different network conditions take testing to judge), or whether features like push notifications are wired up beyond their presence. You also cannot tell why a team adopted partial PWA features. So report the building blocks and installability with confidence, and treat the quality of the offline experience and the worker's internal strategy as things you would verify by testing — for instance, toggling Offline in the Network tab and reloading to see whether the app still works.

Why detecting PWA features matters

Knowing whether a site is a PWA is informative on several fronts. For competitive and product research, a PWA signals a team investing in an app-like web experience — installability, offline support, speed — often as an alternative or complement to native apps, which says something about their platform strategy and technical maturity. For performance, the service-worker caching that underpins a PWA is a genuine speed technique, so its presence overlaps with the work in how to make your website load faster. For technographic profiling, PWA features alongside a modern framework (often React, Vue or Angular — see how to find out what technology a website uses) indicate a current, capable front-end team. And for anyone building a site, inspecting how a polished PWA configures its manifest and service worker is a practical way to learn the pattern. The building blocks are small to detect but reveal a deliberate engineering choice.

How accurate is PWA detection?

Very accurate for the building blocks. The manifest link, the registered service worker and the install affordance are all directly observable in Chrome DevTools, and Lighthouse actively validates them, so confirming "this site has a valid manifest, a running service worker, and is installable" is reliable. The honest nuances are two: first, read the combination — a manifest without a service worker is not an installable PWA, and a service worker without a manifest is just caching — so a single tag is not a verdict; second, the quality of the offline experience and the worker's internal caching strategy take testing (toggle Offline and reload) rather than mere detection to judge. So "does this site have PWA features, and is it installable?" is answerable with confidence, while "how good is its offline behaviour in every case?" needs a hands-on check. Confirm the building blocks in the Application tab and Lighthouse, and you have a solid, honest read.

The workflow

  1. Open Chrome DevTools → Application; read the Manifest pane for a valid manifest.
  2. Check Service Workers in the same tab (or run navigator.serviceWorker.getRegistrations()).
  3. Look for the install option in the address bar/menu — the practical installability test.
  4. View Source for <link rel="manifest">, theme-color and the service-worker registration.
  5. Run Lighthouse for a validated pass/fail on the PWA/installability criteria.

Go deeper

Want a site's PWA features, performance and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.

Frequently asked questions

How do I tell if a website uses PWA features?

Open Chrome DevTools and go to the Application tab. The Manifest pane shows whether the site has a web app manifest (linked via <link rel="manifest">) and its contents, and the Service Workers pane shows whether a service worker is registered and active. Those two — a valid manifest and a registered service worker, over HTTPS — are the defining PWA features. View Source also reveals the manifest link and any theme-color meta tag quickly.

What is a web app manifest?

It is a JSON file (usually manifest.json or manifest.webmanifest) that describes how the site should behave when installed as an app: its name, icons, start URL, display mode (standalone, fullscreen), theme and background colours, and orientation. The page links to it with <link rel="manifest" href="...">. The manifest is what lets a browser present the site as an installable app with its own icon and window, so finding a valid one is a core PWA signal.

How do I check for a service worker?

In Chrome DevTools, open the Application tab and select Service Workers in the sidebar. If one is registered, you will see its script URL, status (activated and running), and controls to update or unregister it. You can also type navigator.serviceWorker.getRegistrations() in the Console to list registrations. A registered, active service worker is what enables offline support, caching and other PWA capabilities behind the scenes.

What makes a site installable as a PWA?

Chrome's baseline criteria are: the site is served over HTTPS, it has a valid web app manifest with the required fields (name, icons, start URL and a display mode), and it registers a service worker. When those are met, the browser offers an install option — an icon in the address bar or an 'Install app' menu item. So installability is the practical confirmation that the PWA building blocks are not just present but correctly configured together.

Can a site have some PWA features but not be a full PWA?

Yes, and it is common. A site might link a manifest and set a theme-color for a polished mobile look but register no service worker, so it is not installable or offline-capable. Or it might run a service worker purely for caching without a manifest. So the presence of one signal does not mean a full PWA — you read the combination. A manifest plus a registered service worker plus HTTPS is the set that defines an installable PWA.

Analyse any website with StackOptic

Get the full technology stack, performance, security and SEO report in seconds — free.

Analyse a website

Related articles