HTML App-Readiness Checker

Valid is not the same as app-ready

The W3C validator asks one question: does this markup follow the spec? A page can pass and still open as a white screen inside an app, because an app is a different environment — no web server, a file:// origin with browser restrictions attached, no address bar, and sometimes no network. This checker looks for the failures that come from that environment. Every rule exists because it has broken a real conversion.

The file:// origin

Bundled pages are loaded from the device's storage, not a server, so their origin is file://. Browsers treat it as uniquely restricted and three things stop working:

• type="module" scripts — fetched under CORS rules that file:// cannot satisfy. No JavaScript runs, the console blames CORS, and the page is blank. The single most common reason a converted site opens empty.
• fetch() of local files — a bundled data.json fails the same way; remote HTTPS APIs are fine.
• Service workers — never register without a secure origin. Any offline logic in one is inert, though a bundled app is already offline.

Two remedies: build modules into one classic script, or have the app serve bundled files from a small local HTTP server so the origin becomes http://localhost. The HTML to App builder takes the second route.

Paths that only exist on your machine

C:\Users\me\site\style.css works until the page is packed, at which point that file does not exist. Root-relative /css/style.css is nearly as fragile once the content lives somewhere other than a web root. Relative paths — style.css, ./img/logo.png, ../about.html — survive the move.

Plain HTTP and mixed content

Android blocks cleartext HTTP by default since Android 9, and a WebView showing an HTTPS page silently refuses HTTP subresources. No dialog — just a missing image or an unstyled page. Every absolute URL should be HTTPS.

The viewport tag

Without <meta name="viewport" content="width=device-width, initial-scale=1"> a WebView assumes a 980 px desktop layout and zooms out, so a responsive site appears as a tiny copy of itself. One line decides whether your responsive design is used or ignored. The opposite error is user-scalable=no, which blocks zooming — an accessibility failure reviewers notice.

What is not checked

This is not a full HTML5 conformance validator and cannot catch runtime problems such as a script that throws on an older WebView. Use it alongside the W3C validator, and test the finished app on a real device — still the only complete check.