{"id":14506,"date":"2026-09-24T10:31:28","date_gmt":"2026-09-24T10:31:28","guid":{"rendered":"https:\/\/playgama.com\/blog\/?p=14506"},"modified":"2026-09-24T10:31:28","modified_gmt":"2026-09-24T10:31:28","slug":"what-are-the-threading-and-runtime-restrictions-of-unity-web","status":"publish","type":"post","link":"https:\/\/playgama.com\/blog\/business-faqs\/what-are-the-threading-and-runtime-restrictions-of-unity-web\/","title":{"rendered":"What are the threading and runtime restrictions of Unity WebGL export?"},"content":{"rendered":"

Unity WebGL executes on the browser’s single main thread by default, so C# threads and blocking waits (Thread, Task.Wait, synchronous file\/network I\/O) don’t work as on desktop. Multithreading is possible only via WebAssembly threads (Web Workers + SharedArrayBuffer), which requires COOP\/COEP headers on the hosting server and browser support.<\/strong><\/p>\n

At a glance<\/h2>\n\n\n\n\n\n\n\n
Fact<\/th>\nValue<\/th>\nSource<\/th>\n<\/tr>\n<\/thead>\n
Default WebGL execution model<\/td>\nsingle main thread<\/td>\ndocs.unity3d.com<\/a><\/td>\n<\/tr>\n
Real threading requires<\/td>\nWebAssembly threads + COOP\/COEP<\/td>\ndocs.unity3d.com<\/a><\/td>\n<\/tr>\n
Calling browser JS from C#<\/td>\n.jslib plugin<\/td>\ndocs.unity3d.com<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

By default a Unity WebGL build runs entirely on the browser’s main thread. There is no OS-level threading the way desktop or mobile builds get it: System.Threading<\/code> objects either don’t behave as expected or the project has to be built with WebAssembly threads support enabled, which compiles worker-based threads backed by SharedArrayBuffer<\/code>. That mode only works if the hosting page serves the correct cross-origin isolation headers (COOP\/COEP) and the visitor’s browser supports it – if either is missing, the build falls back to the single-threaded path.<\/p>\n

If you need the same game running across many platforms, Playgama Bridge<\/a> is an open-source SDK with a Unity plugin that wraps these browser calls so you write the integration once instead of a separate .jslib bridge per target platform.<\/p>\n

Practical rules that follow from this: don’t block the main thread with synchronous waits (no busy loops on Task.Wait()<\/code> or blocking socket calls); keep heavy CPU work inside jobs\/Burst where possible so it can run on worker threads once enabled; and treat any code path that assumes real parallel threads as untested until you’ve confirmed the target browsers and your CDN\/server headers support it.<\/p>\n

Calling into browser JavaScript (for ads, storage, or platform SDKs) goes through a .jslib<\/code> plugin placed in the project, per the Unity manual on interacting with browser scripting<\/a>. Godot’s equivalent is the JavaScriptBridge singleton in Godot 4.<\/p>\n

Where to publish once the build runs: itch.io hosts HTML5 games in an iframe on its own domain; GameDistribution, Poki and CrazyGames each have developer portals for submitting WebGL builds; playgama.com is a portal where you upload via developer.playgama.com and get test feedback before it’s distributed to partner portals.<\/p>\n

Sources<\/h2>\n