DigitalDomainKit's PWA Compatibility Checker reviews one public web page for the basic HTML markers commonly associated with Progressive Web App setup. Enter a full http:// or https:// URL, run the audit, and the tool reports a weighted score based on HTTPS, a manifest link tag, service worker registration hints, viewport metadata, theme color metadata, and iOS app-mode metadata.
This is a server-side public URL feature check, not a full Lighthouse audit and not a browser install test. The checker fetches the submitted page from the DigitalDomainKit server, inspects the returned HTML and response headers, and applies simple marker-based rules. It does not open the page in Chrome, install the app, test offline navigation, run a performance trace, fetch every linked asset, or prove that a browser will show an install prompt. Use it as a quick first-pass review before deeper manual testing.
What the PWA Compatibility Checker Actually Checks
The inspected implementation validates the input as a URL, normalizes it through shared public-target validation, and then sends a server-side HTTP request with a 15 second timeout. Automatic redirect-following is disabled before the page is audited. That behavior is intentional: it avoids silently auditing a different URL than the one you entered and reduces the risk of server-side requests reaching private or reserved network targets through redirects.
After a successful response, the checker looks at the fetched HTML for six specific conditions. The scoring is intentionally narrow, so the result should be read as "these visible setup markers were found" rather than "this site is a complete, installable PWA." A high score is a useful sign that the page includes common building blocks, but it is not a substitute for checking the linked manifest file, service worker behavior, icon quality, offline routes, cache strategy, browser console warnings, and installability requirements on target devices.
| Check | Points | How this tool detects it | Important limitation |
|---|---|---|---|
| HTTPS Encryption | 20 | The submitted URL begins with https://. |
It does not perform a full certificate-chain, mixed-content, or HSTS review. |
| Web App Manifest | 25 | The fetched HTML contains a <link rel="manifest"> tag. |
It does not fetch or validate the manifest JSON, icons, display mode, scope, start URL, or screenshots. |
| Service Worker | 25 | The HTML contains visible registration snippets such as serviceWorker.register or a direct /sw.js registration pattern. |
It does not fetch the service worker file, run it in a browser, or confirm offline behavior. |
| Viewport Tag | 10 | The HTML contains a <meta name="viewport"> tag. |
It does not verify responsive layout quality or mobile usability. |
| Theme Color | 10 | The HTML contains a <meta name="theme-color"> tag. |
It does not test how different browsers use that color in installed or browser UI surfaces. |
| iOS App Mode | 10 | The HTML contains <meta name="apple-mobile-web-app-capable">. |
It does not test Add to Home Screen on Safari or verify iOS-specific icons and startup images. |
How to Use the Tool
- Open the PWA Compatibility Checker and keep the tool form visible near the top of the page.
- Paste a complete public page URL into the Enter Website URL field. Include
https://orhttp://; a bare domain is not enough for this validator. - Click Audit PWA Status.
- Wait while the server fetches the page. The request has a timeout, so very slow or unreachable pages can return an error instead of a score.
- Review the score and individual pass/fail markers. Treat failed rows as places to inspect in your page source, manifest setup, or service worker registration code.
- If the URL redirects, test the final destination URL directly. The checker does not automatically follow redirects before scoring.
- Use a browser-based audit such as Lighthouse or manual device testing for install prompts, offline support, performance, accessibility, and user experience validation.
Inputs, Outputs, and Validation Behavior
The input is a single public HTTP or HTTPS URL. The current validation blocks local, private, loopback, reserved, and similar non-public targets before the server-side request is made. For example, local URLs such as http://127.0.0.1 are rejected with a clean public-target error instead of being fetched from the production server. Public URLs such as https://example.com pass target validation and can be audited if the remote server returns a successful response.
The output is a score out of 100 plus individual marker results. If the remote page does not return a successful HTTP response, the tool reports the status rather than scoring the HTML. Because redirect-following is disabled, a 301, 302, 307, or 308 response should be handled by copying the destination URL and auditing that final page directly. This makes the audit more explicit and avoids hiding redirect behavior that may matter during deployment.
| Situation | Expected result | What to do next |
|---|---|---|
| Public HTTPS page returns HTML successfully | The checker scores the visible HTML markers. | Use the failed items as a setup checklist, then run a deeper browser audit. |
| Public HTTP page returns HTML successfully | The page can be checked, but the HTTPS item fails. | Move the production app to HTTPS before expecting service worker support or installability. |
| URL redirects | The tool may report the redirect status instead of following it. | Audit the final canonical HTTPS URL directly. |
| Localhost, loopback, private IP, or reserved network target | The request is blocked with a public-target validation error. | Deploy to a public test URL if you want this server-side checker to inspect it. |
| Slow, blocked, or unavailable remote server | The audit can fail or time out. | Confirm the page is reachable from the public internet and try again later. |
Understanding the Score
The score is a weighted presence check. HTTPS, manifest linkage, and service worker registration receive the most points because they are central to many PWA setups. Mobile-related metadata receives smaller point values because those tags support the presentation layer but do not prove installability by themselves. For example, a page that is served over HTTPS and includes a viewport tag but has no manifest link, no service worker registration hint, no theme color, and no iOS app-mode tag would score 30 out of 100 under the current method.
That number is useful for triage, but it should not be treated as a quality grade. A site can pass the manifest-link check while linking to a missing, invalid, or incomplete manifest file. A page can include a service worker registration string while the actual worker script fails to install. A site can include mobile meta tags and still render poorly on a phone. Conversely, a sophisticated app can register a service worker through bundled JavaScript in a form this simple string search does not recognize. Read the score as a prompt for investigation, not as a certification badge.
What This Tool Does Not Do
The checker does not run Google Lighthouse, Chrome DevTools, PageSpeed Insights, WebPageTest, or a headless browser installability audit. It does not load JavaScript modules, wait for client-side rendering, inspect the browser console, trigger service worker lifecycle events, check cache contents, simulate offline navigation, or verify push notification support. It also does not check Core Web Vitals, accessibility, SEO crawlability, app shell architecture, or performance budgets.
It also does not make a legal, security, or privacy determination about the site being checked. The public-target validation is designed to keep the server-side fetch focused on public web pages, but the audit still sends a request from DigitalDomainKit infrastructure to the submitted URL. Only audit URLs you are comfortable requesting from a third-party web tool, and avoid submitting unpublished client staging URLs unless that use is permitted for your project.
Practical PWA Follow-Up Checklist
After this first-pass check, inspect the pieces that the marker scan cannot fully verify. Open your page source or browser DevTools and confirm that the manifest link resolves with the correct content type, valid JSON, useful names, valid icon paths, and a suitable start_url. Review the service worker registration in the browser Application panel, then test reload behavior, update handling, offline fallback routes, and cache cleanup. Finally, test on the platforms your users actually use, because Chrome on Android, desktop Chrome, Edge, Safari, and iOS web clips do not expose every PWA capability in the same way.
| If the checker reports this | Manual follow-up | Helpful DigitalDomainKit tool |
|---|---|---|
| Manifest missing | Add a real manifest file and link it from the document head. | PWA Manifest Generator for a starter manifest structure. |
| HTTPS failed | Confirm the production URL, certificate, and redirect plan. | SSL Checker for certificate inspection. |
| Redirect status instead of score | Find and audit the final destination URL. | Redirect Checker for mapping redirect hops. |
| HTTP response error | Check whether the page is reachable from outside your network. | HTTP Status Code Checker for single URL response tests. |
| Security setup needs review | Review headers that support secure browser behavior. | Security Headers Auditor for response-header presence checks. |
Technical References
For deeper implementation work, compare your results with primary browser documentation. MDN's Progressive web apps documentation explains the larger PWA model. MDN's Web App Manifest documentation covers manifest members and examples. The Service Worker API documentation explains registration, lifecycle, caching, and network interception concepts. Google's Learn PWA guide is also useful when you need a practical browser-testing path after this lightweight scan.
Troubleshooting
| Problem | Likely cause | Recommended action |
|---|---|---|
| The URL works in my browser but the checker reports a redirect status. | Your browser follows redirects automatically, while this audit intentionally does not. | Use a redirect checker, copy the final URL, and audit that final public HTTPS page. |
| The manifest is installed on my site but the tool says it is missing. | The current scan looks for a visible <link rel="manifest"> tag in the fetched HTML. |
Check whether the tag is server-rendered, hidden behind client-side rendering, malformed, or present only on a different route. |
| The service worker exists but the service worker check fails. | The registration may be bundled, minified, dynamically generated, or written in a pattern the string search does not detect. | Verify the service worker in browser DevTools and treat this checker's row as a limited hint. |
| A private staging URL is rejected. | The tool blocks private, local, loopback, and reserved targets before server-side fetching. | Use a public staging URL or run browser DevTools locally inside your own network. |
| The score is high but the app still will not install. | Installability depends on requirements beyond these six markers. | Run Lighthouse or browser DevTools and inspect manifest validity, icons, service worker status, scope, start URL, and console warnings. |
Editorial Notes
This page is built and maintained by Digital Domain Kit. The verified technical method, last reviewed on September 16, 2026, is a server-side fetch of a validated public HTTP(S) URL followed by six HTML-marker checks with automatic redirect-following disabled. The recent target-validation repair was retested with https://example.com without a target-validation error and http://127.0.0.1 returning a clean public-target error. To report a problem with this tool or suggest a more complete PWA audit workflow, use the DigitalDomainKit contact page.