This section provides an overview of the platform support and other useful technical information required to build your app using WebGL.
Unity uses the emscripten compiler toolchain to cross-compile the Unity runtime code (written in C and C++) into WebAssembly (also known as Wasm). The main advantages of emscripten it’s designed to be small in size, load-time and memory efficient, and aims to deliver close to native speed execution. For more information about WebAssembly in Unity, check this blog post.
To convert the .NET game code (your C# scripts) into WebAssembly, Unity uses a technology called IL2CPP. IL2CPP takes .NET bytecode and converts it to corresponding C++ source files, which is then compiled using emscripten to convert your scripts to Wasm.
Most popular desktop browser versions support the Unity WebGL content, but do note that different browsers offer different level of support. For example, Unity WebGL doesn’t support Mobile devices.
The following features in WebGL builds are either not available or limited due to constraints of the platform itself:
Threads are not supported due to the lack of threading support in JavaScript. This applies to both Unity’s internal use of threads to speed up performance, and to the use of threads in script code and managed dlls. Essentially, anything in the System.Threading namespace is not supported.
Debugging of WebGL builds in Visual Studio. See: Debugging and trouble shooting WebGL builds.
Browsers don’t allow direct access to IP sockets for networking due to security concerns. See: WebGL Networking.
Limitations with the WebGL graphics API, which is based on the functionality of the OpenGL ES graphics library. See: WebGL Graphics.
WebGL builds use a custom backend for Audio, based on the Web Audio API but only supports the basic audio functionality. See: Using Audio in WebGL.
WebGL is an AOT platform, so it doesn’t allow dynamic generation of code using System.Reflection.Emit. This is the same on all other IL2CPP platforms, iOS, and most consoles.