Valid HTML and app-ready HTML are not the same thing
The W3C validator answers one question: does this markup follow the spec? Useful, but it will happily pass a page that renders as a blank screen inside an Android app. A page becomes app-ready when it survives a different environment — one with no web server, no address bar, an old rendering engine on some devices, and often no network at all.
This checker looks for the failures specific to that environment. Every rule below comes from something that actually breaks conversions.
The file:// problem, which catches nearly everyone
When your site is bundled into an app, the pages are loaded from the device's filesystem rather than a server — the URL is file://, not https://. Browsers treat that as a unique, restrictive origin, and three things stop working:
- ES modules.
<script type="module">is fetched with CORS rules, and a file:// origin fails them. Your JavaScript never runs, and the console error mentions CORS rather than modules, so the cause is not obvious. This is the most common reason a converted site opens blank. - fetch() on local files. Loading a local
data.jsonfails for the same reason. Remote https:// APIs are unaffected. - Service workers. They require a secure origin and simply never register. Any offline logic you wrote does nothing — though a bundled app is already offline, so you lose little.
There are two ways out: build your modules into a single classic script, or serve the bundled content from a tiny local HTTP server inside the app so the origin becomes http://localhost. Our builder takes the second approach for exactly this reason.
Paths that only exist on your computer
A page referencing C:\Users\me\site\style.css works perfectly until it is packed into an app, at which point that file does not exist. The same goes for root-relative paths like /css/style.css once the content is unpacked somewhere other than a web root. Relative paths — style.css, ./img/logo.png, ../about.html — are the ones that survive the move.
Mixed content and cleartext HTTP
Android has blocked cleartext HTTP traffic by default since Android 9, and a WebView showing an https page refuses to load http subresources at all. In both cases the resource fails silently: no error dialog, just a missing image or an unstyled page. Every URL in your markup should be https, or relative.
The viewport tag decides whether your site looks like an app
Without <meta name="viewport" content="width=device-width, initial-scale=1">, a WebView assumes a 980px desktop layout and zooms out to fit, which is why a converted site can appear as a tiny, unreadable version of itself. It is one line, and it is the difference between a responsive design working and being ignored entirely.
The reverse mistake is user-scalable=no. It stops users zooming — an accessibility failure that reviewers do notice, and one that helps nobody once your layout is genuinely responsive.
What this tool does not check
It is not a full HTML5 conformance validator: it does not verify every attribute against the spec, and it cannot catch problems that only appear at runtime, like a script that throws on an older WebView. Run it alongside the W3C validator rather than instead of it — and test the finished app on a real device, which remains the only way to be sure.