New for WebGL in 2022 LTS


I’m Ben Craven, the Product Manager looking after the web platform at Unity. We have a number of new features that were released along with 2022 LTS. This is a step forward for us on Web, and we are excited to share even more as we continue investing in this platform!

  • Added a template for Progressive Web Apps
  • Added mobile keyboard support for WebGL to enter text in UI input fields.
  • Added texture compression format setting to WebGL build & player settings
  • Updated Emscripten compiler to version 3.1.8
  • Experimental option to enable native multithreading (not C# multithreading) for WebGL builds
  • Support Entities 1.0 release on WebGL
  • Stabilized Unity performance profiler, along with Unity test framework when used with WebGL builds
  • Memory Management/Diagnostics in Publishing Settings

  • New player settings for fine-grained control over memory usage, including memory scaling and growth (Player Settings > Publishing Settings > Memory Growth Mode [Linear vs. Geometric])

  • New diagnostic overlay to measure memory usage. (Player Settings > Publishing Settings > Show Diagnostics Overlay)

  • Removed mobile browser warning from WebGL default template.

  • While the warning is removed, we have not yet added mobile browsers to our list of formal supported browsers. Stay tuned to hear more about web on mobile in the near future!

For everything new included in 2022 LTS, check out our LTS release hub here:


Thanks!!! Thanks!!! Thanks!!!
WEBGPU :eyes:


I've asked this a couple times, and I've seen others ask this as well. However, I haven't found an answer yet about it. Does the native multithreading include Jobs since they are managed by native threads?

1 Like


I've a specific question on one of your points:

I'm actually already doing the same thing since months but I found out that, doing it like this, you can't specify an ASTC compression quality other then "low/normal/high quality" so "8x8/6x6/4x4". Actually to have a lower build size sometimes I see I can also use 12x12 and I'm forced to use "Override for WebGL" that make the texture in ASTC for both builds... Is there a workaround on this or can you put in some todo list?

PS: there is a typo in the documentation page, I already reported it.

Thanks for your feedback on the documentation! I've corrected the typo. The update will be visible when the docs are updated on Tuesday.

1 Like

@AlwaysCraven , thank you for the introduction and list of 2022 LTS features, much appreciated.

Would it be too early for you to also share the 2023.1 Tech Stream WebGL features & changes as it has now been released out of beta?

I been doing some builds with Unity in WebGPU.
Builds fine as long as you update to the Shader Names for WebGPU.

@DudoTheStampede Hi, I'd like to help! Could you clarify a little what issue you're facing with setting the texture compression? I didn't quite understand. Is this about the script in the docs for making two builds with different compression formats?

The script is good, the problem is in the editor itself. I'll try to explain with an example:
I've a texture and I'd like that texture to be ASTC 12x12 on mobile, and "something else" on desktop. With this kind of setup I can't have it with just one build. In Unity Editor, by Default, I can only make the texture as "Compression: Low Quality", but "Low Quality", when building for mobile, is ASTC 8x8.
To have a texture as ASTC12x12 you have to use "Override for WebGL". But you use that, both desktop e mobile build will have that texture as ASTC12x12.
So you would either need a multiple "Override for WebGL", or a "Lowest" quality option in the compression dropdown... or some other kind of magic trick to perform in the build script to achive that!

1 Like

@unityruba Hi, i have two bug report, one is already confirmed here:
and the other one is currently open (i still don't have a bug report to link): CASE IN-53225.
These to bugs concern this: "mobile keyboard support for WebGL to enter text in UI input fields".
At the moment is nearly impossible to use it properly because: only number input fields doesn't work and when you press the ok button on the virtual keyboard or the enter button, the application crash. From my point of view i don't understand how is it possible that this is a released feature if it doesn't work properly, and i don't mean like a strange bug that happens in rare circumstances, you can literally open a brand new project import a TMP_InputField, build and you can discover them.

Thanks for this update, it looks great. Can you provide some info on whether there is a maximum memory size in the browsers? Both desktop and mobile?

Thank you for that and for the considering of the mobile support in the future. Please pay attention to my bug report, which was abandoned, actually, and not postponed!

Maybe you can affect it:

Is webgl build is safe for mobile browser to use in production?

I am using Cesium-for-Unity plugin to create apps that utilize real world terrain and gis-data. I found that native c/c++ can be embedded inside unity webgl and I was thinking to publish my app with cesium into webgl application. The plugin is mostly c++ (Cesium Native) and the c++ files and headers are available.

I attempted to build Cesium Native's source code into Unity for a WebGL build, but encountered some obstacles. The primary issue seems to be related to Unity's handling of source code, particularly for native libraries. Unity seems to lack a mechanism to effectively segregate or label C/C++ source files when dealing with multiple plugins. As a result, it merges all header files into a single directory during the Emscripten compilation process. This approach is problematic for Cesium Native, as it uses identical header file names across different directories. Furthermore, the external libraries Cesium Native relies on also exhibit this issue of identical header names. To address this, it's necessary to individually compile these external libraries and Cesium Native's own code into separate WASM libraries using Emscripten. These compiled libraries can then be integrated into the Unity project. The entire process, including setting up the libraries and compiling both the third-party dependencies and Cesium Native sources into WASM format, is time-consuming.

Is this something that could be handled in the recent or coming versions of Unity so that all the native code does not need to be refactored but Unity Build system could support multiple header files with identical names? Or do You have any other thoughts how this could be handled more easily?

Before you dive any further into that, have you asked the Cesium developers whether their C++ code is compatible with WebGL to begin with?

Just because Unity supports native C++ DLLs in WebGL doesn't mean you can compile ANY C++ code for WebGL, not even when the DLL works with other Unity platforms.


There have been many threads where people are asking to support unity Webgl and the Cesium developers usually are saying that it is not on their roadmap, they are not sure will it work and and at least it probably is going to be quite a lot of work. Personally I do not know what limitations there is currently in Webgl that I should check. Anyway this got my interest because all the source code in c++ is available and the same Cesium Native c++ plugin was recently built to html5 via Unreal Engine ( I Think this would be very good if the whole globe 3D model like Google's photorealistic 3D tiles could be used with Unity to generate real world games and apps into web.