What "won't open" usually looks like

There are three common symptoms, and they point in different directions:

  • Fully blank white or black screen, no errors visible — often a rendering/context issue or a browser silently blocking a local script.
  • Console errors on load ("Failed to load resource," "Cross origin requests are only supported for protocol schemes: http, data, chrome...," a syntax error, a 404) — almost always points at a specific missing file or how the export is being opened.
  • Loads, then hangs or stalls partway — usually an incomplete asset cache, where some of the build's compressed data never finished writing.

Real causes, in order of likelihood

1. Missing or misnamed entry file

Every network-ready package needs an HTML file to act as the entry point, and it has to be named and placed correctly. A folder-mode Playworks/Luna export needs index.html at the root — not nested in a subfolder, not renamed. Single-file exports are worse to eyeball: if you're testing a build meant for Mintegral, the entry file isn't index.html at all, it's <package-name>.html, matching the archive and folder name exactly. Open the wrong file — or the right file from the wrong location — and the browser just renders nothing, because the script paths it expects don't resolve from where you opened it.

2. Incomplete engine/scripts.js or a partial Luna cache

A working export needs either a standard engine/scripts.js file (folder mode) or a complete cache set — cache/<id>/scripts.js, jsons.js, and blobs.js all present for the same cache ID (single-HTML mode). If any one of those three is missing, the export has no usable cache at all, even though the other two files are sitting right there. This is exactly what PlayableKit's own conversion pipeline checks for before it will build anything — if it can't find a complete {scripts, jsons, blobs}.js triplet under any cache ID, it fails outright rather than guessing.

3. A single-HTML export opened from the wrong file

If you were handed a single self-contained .html file (AppLovin- or Meta-style output, or a Playworks/Luna single-file export) but you're trying to open it alongside a cache/ or engine/ folder that's actually for a different build, you'll get a file that half-loads or throws reference errors from mismatched script versions. Single-file exports are meant to be opened completely standalone — no sibling folders required, no relative paths to anything else on disk.

4. The browser blocking local file:// execution

This is the most common cause and the easiest to miss, because the export itself is perfectly fine. Modern browsers apply strict cross-origin rules to anything loaded via file://: certain script and fetch requests that would work over http:// get silently blocked, producing exactly the "Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https" error, or just a canvas that never receives its data. If your only symptom is a blank screen with that specific error in the console, the export is very likely not broken — the browser is just refusing to load it as a local file.

5. A corrupted or partial export from an interrupted Unity build

If the Unity build was cancelled, crashed, or the export ZIP was copied before Unity finished writing it, you can end up with a ZIP that's truncated or missing entries entirely — a partially-written cache file, an HTML file cut off mid-tag, or a ZIP that a standard archive reader can't even open. This produces different symptoms depending on what got cut off: sometimes a hard read error, sometimes a build that loads assets partway and then hangs.

How to actually diagnose it

  1. Serve it locally instead of opening file://. Run a throwaway static server in the export folder — npx serve or python -m http.server — and open it over http://localhost. If the blank screen disappears, cause #4 was it, and the export was never broken.
  2. Check the console for the specific error, not just that an error exists. A 404 on a named file tells you exactly what's missing; a cross-origin message points at file:// itself; a syntax error points at a corrupted or truncated file.
  3. Run the export through the free Playable Ad Validator. Upload the raw ZIP and it checks, in seconds, for exactly the structural issues above: whether index.html exists at the archive root, whether engine/scripts.js or a complete cache/<id>/{scripts,jsons,blobs}.js set is present, whether the inline scripts even parse without a syntax error, and whether a recognizable click-through hook exists. No signup, no upload retained beyond the check.
Worth knowing: missing assets specifically — as opposed to a missing entry file — are common enough to warrant their own breakdown. See Unity Playworks/Luna export missing assets if your build opens but textures, audio, or the end-card don't show up.

How PlayableKit handles a broken export instead of hiding it

When you run a real conversion rather than just opening the raw export, PlayableKit doesn't fail the whole job the moment one thing is wrong. Its converter processes each target network independently, and if a specific network's build hits exactly one of the issues above — no complete cache, a missing index.html, an unexpected export shape — that failure is caught per network and turned into a CONVERSION_ERROR finding with the actual error message, written into conversion-report.json alongside the networks that converted fine. You get a clear, per-network verdict instead of either a silent broken package or a build that stops dead on the first problem. That report is exactly what surfaces click-through issues too, which is its own common failure mode once the build actually opens — see Unity Playworks/Luna click-through not working if that's what you're seeing next.