Why Does My Godot Web Build Run in the Editor but Stop in the Browser?

This trap is easy to misread, because the failure looks like a broken build. The editor run works, so you reopen scripts, re-export, and suspect the newest change. None of that helps when the cause sits below the game, in the contract between the host and the browser. A threaded export asks the browser for shared memory through SharedArrayBuffer. The browser answers by checking the page, not the game. If the page is not cross-origin isolated, the answer is no.

Godot 4.3 changed how often this trap fires. Before it, multi-threaded web export made sense for audio and performance, and the header requirement came with it. Since Godot 4.3, Godot supports a single-threaded export that solves the header problem by not asking for threads at all. The documentation calls it the preferred and now default way to export for the web. A developer who leaves the defaults alone and never turns Thread Support on may never meet this trap. The developer who does meet it usually has an older threaded export, a project that genuinely uses the Thread class or GDExtension features on the web, or a project that turned Thread Support on for low-latency Stream audio without noticing the hosting requirement it bought.

For a threaded export, the Godot documentation is blunt. Only when exporting with Use Threads do Godot 4 web exports use SharedArrayBuffer, to keep audio latency low and to allow the Thread class on the web. That use requires a secure context and two response headers on the served files: Cross-Origin-Opener-Policy set to same-origin, and Cross-Origin-Embedder-Policy set to require-corp. Together they put the page into cross-origin isolation, the state the browser demands before it hands out shared memory. The documentation then states the consequence plainly: if the client does not receive the required response headers, and the service worker workaround is not applied, the project will not run.

Two related facts explain why the editor run misleads, and why the header fix is not free. First, a desktop run in the editor is not a browser page, so it never has to pass the browser isolation check. Second, cross-origin isolation is a whole-page deal: the documentation warns that it means no ads and no third-party integrations on the website hosting the game. Turning threads on is therefore a hosting choice, not only a performance choice.

Because no named incident verified, here is the honest substitute: a reproduction on your own smallest project, on a test deployment. Make a tiny Godot 4 project that uses a thread in a visible way, for example a background task whose result appears on screen. Export it for the web with Thread Support turned on. Upload it to a test host that does not send the two isolation headers, open the page, and check in the developer console whether the page reports itself as cross-origin isolated. Then repeat the test one changed condition at a time: first with the two headers present, then separately with the Progressive Web App route below. If the first test fails and either changed condition passes, the cause is the hosting contract, not the game. Do this on a test deployment only, never by editing the only configuration of a live site without a backup and a way back.

The three routes out are: turn Thread Support off and re-export single-threaded, accepting that the Thread class is unavailable and that default Sample audio limits audio effects and procedural audio; keep threads and make the host send exactly the two headers above in a secure context; or, for a host you cannot configure, enable Progressive Web App in the export options, which installs a service worker that simulates the headers while still requiring a secure context. Keep Enable Cross Origin Isolation Headers checked, or that route stops working. If a retest shows yesterday's build, unregister the current service worker in the developer tools and reload, which is the panel shown in the cover image. Whatever route you choose, re-export after changing an export option, because direct edits to the generated HTML file are lost on future exports.