Fix: Construct 3 Web Worker Not Loading or Causing Blank Screen

Construct 3’s worker mode is one of its most useful features — and one of its most common sources of mysterious blank screens. If you’ve exported your game, uploaded it to itch.io or your own server, and been greeted with nothing but a white or black canvas, the Web Worker is almost certainly the culprit. This post walks through exactly why it fails, how to diagnose the specific error in your browser’s console, and your two paths to a fix: configuring the required server headers or disabling the worker entirely.

Why Construct 3 Uses a Web Worker

By default, Construct 3 runs your game’s event sheet logic inside a Web Worker — a separate background thread that the browser provides for running JavaScript off the main thread. The main thread in a browser tab is also responsible for rendering, handling UI events, and running browser housekeeping tasks. By moving game logic to a worker, Construct 3 keeps the main thread free for rendering, which results in smoother frame delivery and better performance on multi-core devices.

The worker mode is controlled by the “Use worker” setting in Project Properties → Advanced. It’s enabled by default in new projects. The worker communicates with the main thread using SharedArrayBuffer, a shared memory primitive that lets two JavaScript threads read and write the same block of memory without copying. This is what makes the communication fast enough to drive a real-time game loop.

SharedArrayBuffer is also why servers need special headers. After the Spectre CPU vulnerability was disclosed in 2018, browsers disabled SharedArrayBuffer by default and only re-enabled it on pages that opt in to cross-origin isolation using two HTTP response headers. Without those headers, the browser refuses to make SharedArrayBuffer available, the worker can’t initialize, and your game shows a blank screen — often with no visible error to the player.

Reading the Actual Error in DevTools

Before you change anything, open your browser’s developer tools and read the console. Press F12 in Chrome or Firefox, click the Console tab, reload your game, and look at what appears. The error message tells you which of several different problems you’re actually facing.

The most common messages you’ll see and what they mean:

• “SharedArrayBuffer is not defined” or “Cannot read properties of undefined (reading ‘buffer’)” — the browser blocked SharedArrayBuffer because the server is missing the COOP/COEP headers. This is the most common blank-screen cause.
• “Failed to load resource: the server responded with a status of 404 (Not Found)” on c3runtime.js — the exported files aren’t where the server expects them. This is a deployment path issue, not a worker issue.
• “SecurityError: Failed to construct ‘Worker’” — the browser is blocking the worker script itself due to a content security policy or cross-origin restriction on the script URL.
• No error at all, just a blank canvas — the worker loaded but silently crashed. This is most common on certain mobile browsers; see the mobile section below.

Don’t skip this step. The fix is different depending on which error you see, and applying the wrong fix wastes time.

Fix 1: Add the Required CORS Headers to Your Server

If the console shows a SharedArrayBuffer error, the correct fix is to add two HTTP response headers to your server’s responses for your game’s HTML page (and ideally all files in that directory):

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

These headers tell the browser that your page is opting into cross-origin isolation, which re-enables SharedArrayBuffer. Here’s how to add them on common server configurations:

Apache (.htaccess):

Header set Cross-Origin-Opener-Policy "same-origin"
Header set Cross-Origin-Embedder-Policy "require-corp"

Nginx (server or location block):

add_header Cross-Origin-Opener-Policy "same-origin";
add_header Cross-Origin-Embedder-Policy "require-corp";

Node.js / Express:

app.use(function(req, res, next) {
  res.setHeader('Cross-Origin-Opener-Policy', 'same-origin');
  res.setHeader('Cross-Origin-Embedder-Policy', 'require-corp');
  next();
});

After adding the headers, verify them in DevTools under Network → select your index.html → Response Headers. Both headers must be present with the exact values shown above before the worker will load correctly.

itch.io and Newgrounds: What Each Platform Supports

Not all game hosting platforms support the COOP/COEP headers, and the situation differs between them.

itch.io supports cross-origin isolation, but you have to opt in. In your game’s edit page, scroll to the Embed options section and enable “SharedArrayBuffer support (COOP/COEP)”. Once enabled, itch.io serves your game with the required headers and worker mode works correctly. If you don’t see this option, make sure your game is set to run in the browser (not as a download).

Newgrounds does not currently support the COOP/COEP headers for player-hosted games. The Newgrounds player runs games inside an iframe with its own origin, and cross-origin isolation is incompatible with the iframe embedding model they use. If you want to publish on Newgrounds, you need to disable “Use worker” in your Construct 3 project.

GitHub Pages does not send COOP/COEP headers. Use “Use worker” disabled, or use a CDN layer in front of your Pages site that can inject the headers.

Your own server or VPS gives you full control over headers. Add them as shown above and you’re done.

Fix 2: Disable “Use Worker” in Project Properties

If you can’t configure the server headers — because you’re on a platform that doesn’t support them, or because you need your game to work on an embedding site you don’t control — the most reliable fix is to turn off worker mode entirely.

In Construct 3: open Project Properties (the wrench icon in the left sidebar), scroll to the Advanced section, and set “Use worker” to No. Re-export your game and re-upload it. The blank screen will be gone.

The performance trade-off is real but manageable. Without the worker, all game logic runs on the main thread alongside rendering. For most Construct 3 games — platformers, puzzles, visual novels, top-down shooters — this makes no practical difference at 60 fps. If your game has very heavy event sheets with hundreds of conditions evaluating every tick, you may see slightly less consistent frame timing on low-end devices. Test your game thoroughly after disabling the worker and measure whether the frame rate actually changes before deciding you need to solve the header problem instead.

The Silent Failure on Mobile Browsers

There’s a specific scenario worth calling out separately: Construct 3 games that work fine on desktop Chrome and Firefox but show a blank screen on Safari for iOS, or on certain Android browsers. This is different from the server header problem.

Some mobile browsers implement Web Workers with restrictions that don’t appear on desktop. Safari on iOS, in particular, has historically had stricter limitations on worker thread access to certain APIs. The worker may appear to load but then silently crash during initialization, leaving the canvas blank with nothing in the console (because the worker’s console output doesn’t always surface in Safari’s remote debugger).

To debug this: connect your iPhone to a Mac and use Safari’s remote Web Inspector to view the console on the actual iOS device. Alternatively, switch to Chrome on the same iOS device (which uses a different rendering engine on iOS 17+) and see if the problem persists. If the game works in Chrome for iOS but not Safari, the issue is Safari’s worker implementation.

The fix for iOS Safari worker failures is the same: disable “Use worker” and re-export. Cross-origin isolation is required for worker mode, and the iOS Safari implementation of it has been inconsistent across OS versions.

Fixing the c3runtime.js 404 Error

If your console shows a 404 on c3runtime.js, the problem is unrelated to the worker — it’s a file path mismatch. The exported index.html references c3runtime.js as a relative path, so if the files aren’t served from the same directory, the browser can’t find the runtime.

The most common cause: you exported the game to a folder like mygame/ and then uploaded only the contents of that folder to your server root, or conversely, uploaded the entire folder including the parent directory and your URL points one level too high or too low.

The fix:

1. Export your game from Construct 3 to a local folder.
2. Open the exported folder and verify that index.html and c3runtime.js (or c3runtime.worker.js) are in the same directory.
3. Upload the entire contents of that folder to your server, maintaining the exact relative structure.
4. Access the game through the URL that points to that index.html file.

Don’t rename files or restructure the export folder. Construct 3’s export generates internal references between files, and moving them relative to each other breaks those references.

“The blank screen is almost never the game — it’s the environment. Get the console open first. One line of error output saves an hour of guessing.”

Preventing This in Future Exports

Once you’ve confirmed your fix works, put a note in your deployment checklist. It sounds obvious, but a checklist item that reads “verify COOP/COEP headers are present before announcing launch” has saved many developers from a broken release. Use a tool like securityheaders.com or just check the Network tab in DevTools after every upload to a new server or platform.

If you ship to multiple platforms (your own site, itch.io, Newgrounds, an app wrapper), maintain a separate build configuration for each. Construct 3’s project settings allow you to keep “Use worker” enabled for platforms that support the headers and maintain an alternate no-worker export for platforms that don’t. Keeping both as documented export presets avoids the scramble of figuring out which settings you changed last time you shipped to Newgrounds.

Tracking which version of your game is deployed to which platform is also worth doing systematically. If a player reports a blank screen and you’re not sure whether the build on itch.io is the worker-enabled version or the fallback, you have to re-check everything. A simple build log — even a shared doc with one line per release — eliminates that uncertainty.

When the blank screen hits at launch, the console is always the first stop — one header or one 404 is almost always all that’s standing between you and a working game.