Search Unity

With Google about to complete the deprecation of NPAPI support in their Chrome browser, we’ve been receiving some questions about what the best options are for publishing games on the web and reaching Chrome users at the same time. Given Chrome’s wide usage, these are fair questions.

NPAPI Deprecation

On the off chance that you’re creating web games and hearing about this for the first time, here’s a quick overview. In 2013, Google announced that they would be deprecating and then disabling NPAPI, the plugin framework that Unity Web Player relies on to enable the richest interactive content experiences on the web. Currently, there is a workaround to get the NPAPI support back on in Chrome, but Google plans to completely remove NPAPI support from Chrome in September 2015. There is not an explicit timetable for NPAPI deprecation in other browsers, though it will happen.

Following this announcement, we began serious investigations into alternate avenues for web games. We decided on moving forward with WebGL, which we announced at GDC 2014 and is now available in preview as a build target in Unity 5. You can read more about that here:

The State of WebGL

What seems to be the obvious solution to this is simply to make games in WebGL. While this solution will eventually be excellent and we are working hard on WebGL with browser manufacturers like Mozilla,  Google and Microsoft, the base WebGL technology is still limited in comparison to Unity Web Player. This includes a performance gap we are working to narrow though the issue is made more complicated by widely varying performance in different browsers. For more on WebGL performance, see our earlier blog post here:

WebGL is totally feasible for “lighter weight” web games and apps in it’s current state but it is important to set realistic expectations. It’s unlikely that you’ll be able to simply float your game over from Unity Web Player and expect everything to work perfectly. Heavy games with high performance needs will likely find the WebGL option currently won’t fit their needs due to the aforementioned performance gap, some other platform limitations like networking, and scalability issues due to build sizes and browser-side memory constraints. Unfortunately, because the technology is still in heavy development, both on our side and on the browser side, we cannot provide support through our premium support channel before we have a full release. In the meantime, the best place to discuss WebGL issues is on the forums ( where our developers are very active.

There is a silver lining!

The great news is that Unity and the browser manufacturers are collaborating closely to solve these issues! Everyone involved is very invested in ensuring WebGL achieves its great potential so we have every reason to believe that WebGL will make developer and gamer lives better in the long run.

The State of the Unity Web Player

The Unity Web Player is still the best option for high performance games on the web. Given this, we will continue supporting it for as long as it’s useful for developers.

It’s also very important to note that Unity Web Player still works beautifully on other browsers outside of Chrome, so there are options.

So what do I do if my game needs the Web Player?

If your existing game requires the Web Player to run properly (especially for those of you with complex high performance games), here’s some suggestions of what you can do in the meantime:

Option A: Encourage players to use alternate browsers where plugins are still available. Create a page to pop up when the plugin won’t start that informs people of what has happened and list browsers that still work well with your game.

Option B: Provide instructions on how to allow plugins to function in Chrome before the plug gets pulled completely on NPAPI in September (at which point there is no way to enable NPAPI plugins. Sample instructions follow:

Step 1: In Chrome’s address bar, type: chrome://flags/#enable-npapi

NPAPI enable 1

Step 2: Find “Enable NPAPI Mac, Windows” in the list, and click “Enable”

NPAPI enable 2

Step 3: Hit the “Relaunch Now” button at the bottom of the page

NPAPI enable 3

What if I’m developing something new?

We recommend that those of you creating new web games with Unity start new projects with Unity 5 WebGL as the default target. WebGL games are more limited in terms of functionality and performance than Web Player games, so you can port your game to the Unity 5 Web Player later if you choose and add some additional functionality to leverage the greater capabilities of the Unity Web Player. This way, gamers will be able to play a WebGL game on Mozilla Firefox, Google Chrome, Apple Safari 8.x or play it as a Unity Web player game on Microsoft Internet Explorer, Apple Safari 7.x, or Yandex.Browser which should provide the widest audience possible.

Keep in mind that with Google well on their way to removing NPAPI support from Chrome entirely, other browsers will follow suit. This eventuality (there are no confirmed timetables for this) makes it very hard to recommend beginning new projects with the Web Player in mind at all.

The short of it

WebGL will be amazing – even better than The Unity Web Player because there will be no plugin barrier for players – but there’s no avoiding that it’s not yet as capable as the Unity Web Player and there’s no spectacular technological option to get around the deprecation of the framework that made it possible. We understand this is a rough transition and feel your pain as we would love the Web Player to continue functioning across all browsers, but unfortunately that decision ultimately is not ours to make. For the time being, if you’re maintaining a very complex game that you want to run well on the web, you’ll need to use the Web Player and direct customers to other browsers.

And we’ll keep collaborating with browser manufacturers to make the WebGL platform and our WebGL tools as powerful as we know they can be!

42 replies on “Web Publishing Following Chrome NPAPI Deprecation”

I appreciate that it’s not Unity’s fault but AGAIN I have to pay a lot of money I really don’t have, as I’ve spent loads on Unity but made Nada ( freely admit I must be doing it wrong) to upgrade my license to the “new” version to get something that doesn’t work as well as it does now but shortly won’t work at all anyway because of Eternal Web browser infighting.
It’s hard to hold on to the will to live.

[…] start with the tech first. Things have been a bit hectic as we try to overcome the fact that Chrome has decided to do away with NPAPI support. What this means is that we won’t be able to preview the game in the browser for ourselves […]

I think Unity should create their own browser. One of your recommendations was to have people use an alternate browser anyway. And users have always needed to allow the installation of the Webplayer the first time they clicked a webplayer link, so why not a small completely optimized Unity browser for Webplayer content.

The more I think about this, the better it sounds. I do ArchVis, and the biggest advantage for me using the Webplayer is clients don’t need to download anything new. If I make some changes, they just hit F5. And i’ve never embeded anything anyway, I always use a new clean window. It could evolve into a front end for all things Unity Webplayer related.

Perhaps I’m missing something, but for my clients it would be just as much “friction” to ask them to download a custom Unity web browser as it would to just have them download a native app. The whole promise of the web browser as a target (which has yet to be fully realized) is to eliminate requiring your clients to download something special.

But they would only need to download it once. Currently if I am providing a standalone player, they need to re-download the entire project every time there is an update. There is also the problem of outdated builds floating around. With an interface, think Steam for Unity web content, the one install would access all updates and any future projects in one place.

The sad truth for me is that WebGL isn’t going to be ready enough in September, when Google kills NPAPI. My games are realtime, multiplayer and they use UDP communications. Our business model requires that we’re in the browser and many of our clients (educational institutions) have standardized on Chrome (often, even Chromebooks) because of Google’s services and web apps. Why can’t Unity engineers work with Google engineers to make ARC (App Runtime for Chrome) Welder work with Unity built APKs? At this time, it simply doesn’t work. Even the simplest of ‘Hello World’ apps created in Unity3d fails to launch when run through ARC Welder.

The sad truth for me is that WebGL isn’t going to be ready enough in September. My games are realtime, multiplayer and they use UDP communications. Our business model requires that we’re in the browser and many of our clients (educational institutions) have standardized on Chrome (often, even Chromebooks) because of Google’s services and web apps. Why can’t Unity engineers work with Google engineers to make ARC (App Runtime for Chrome) Welder work with Unity built APKs? At this time, it simply doesn’t work. Even the simplest of ‘Hello World’ apps created in Unity3d fails to launch when run through ARC Welder.

Google is hurting us too… the removal of NPAPI is hurting the users of our enterprise application we use here. So we just ‘force’ the users to either use Firefox or IE.

Chrome’s loss.

[…] play Project Footstool here, provided you have Unity Web Player and don’t use Chrome, since that will cause several issues. Even then though, he’s planning to upgrade to a webGL version at some point, which means […]

I have use WebGL on my machine and Firefox disabled it because my graphic card is supported.
Of course I can Enable WebGl and it work fine when I use it with engine like Pixi.js
But none of the demo on the asset store using WebGl works.
Chrome use to be my default browser but when NAPI’s been deprecated I have just switch to Firefox,
maybe everyone should do the same and we can keep the amazing Unity WebPlayer.
I mean so much work have been put into that.

The millions of Flash guys say ohai…

Seriously though – the web has become something of a sacred cow and until Unity fully supports ‘their’ way of doing things, the only option will be to develop using webgl.

Uh.. 1 or 2 more years to have WebGL at level of current WebPlayer.. that is quite a lot.
Also is WebGL build transforming all Unity dlls into JavaScript all the time? Doesn’t that change only after some Unity patches are being applied, so theoretically it can be cached and removed only with new Unity patch or version.

Why not just port the Unity engine to the the Chrome Portable NAtive CLient API? We just completed our transition to this technology and are satisfied with the performance and features set – best of all is support for C++ 11 and multiple threads.

The developer tools were very difficult, some bugs took weeks to address, but in the end we managed to get our 3D engine up and running on Chrome just fine. The PEXE format is quite flexible too, requiring only a single file to support 32-bit and 64-bit clients on Chrome for Windows, Mac, and Linux. It’s really an amazing piece of cross-platform technology. I can’t stress enough the difficulty of the tools though – it may not be for everyone – some debugging sessions will have you thinking about a career change. I really wish Google would spend some money on better tools.

Sooner or later, every Browser will provide a similar API – a platform for just-in-time compiled native-code components that enable the ultimate web experience, utilizing all the power of that awesome laptop or desktop computer you spent your hard-earned money on. Waiting on the web standards organizations or monopolistic mega corporations is a great strategy for low performance and a ho-hum experience.

Unity already had NaCl support long time ago but I think the support was dropped due low usage vs the costs of maintaining the platform to have all fixes and new features. There was also Flash support which would not have been limited to single browser but it was killed too for some of the same reasons. I don’t think there is any point to implement any deprecating technologies or one browser only solutions. By the time they would have some Chrome specific solution out there in good shape there would be other browser announcing the death of plugin support. I think it was already said Windows 10 default browser wont support em either(?)

That’s sad. Developers ignore my questions about making WebGL building on x86 OS possible.
I replaced both x64 Python and Emscripten folders with x86 ones but it still fails to build on x86 OS . . .
Any suggestions how to build WebGL on x86?

Well, if developers of Unity are silent – then what do You think about it, guys?

Well you asked it before in the wrong blog post which had nothing to do with web publishing.

I think it was said long time ago during U5 beta when someone asked similar question that there were no plans that moment to support 32bit tool chain while the WebGL is only at preview state. I think one of the reasons possibly was memory requirements and one was the thing Jonas said in comments below that emscripten will be replaced with native executable.

What bugs me about this blog post is Google didn’t do this overnight and someone who develops one of the most widely deployed plugins on the web like Unity should have known this was coming months, if not a year, in advance.

Then you make this post where you make it sound like you didn’t know it was happening till the day it happened and then tell people to switch browsers, play with settings they should not be playing with (and won’t figure out) or use your horrible (10 minute+ build times — fix one line of code and wait another 10+ minutes for the next build) webGL.

The web is a very important platform to support, don’t fail it like you did here Unity.

We are certainly not trying to imply that this is something that came overnight and the timeline of awareness is clearly outlined in the blogpost.

We completely share your sentiment on the importance of webpublishing. This is why we are heavily investing in the future of Unity games web-publishing; WebGL. Unfortunately, Google’s decision to pull NPAPI came before browsers are ready to offer completely parity without plugins. While that on itself is a negative at the same time we are continuing our work with browser vendors so parity can be reached in the future.

Working on WebGL for over the last 3 years, we’ve stood at the cradle of the technology needed to truly replace plugins on the web. We don’t believe it’s there today yet, but we will continue and push the web as a platform.

Yeah, I didn’t get the sense at all that they were implying any bit of surprise, and like Ralph said, the post clearly outlines Unity’s activity from the very beginning. You say Unity should have known this was coming a year in advance… They knew well MORE than a year in advance; that’s sort of why they have a beta webGL build function right now.

That game came out 16 years ago.. by any metric it’s not a good example to prove your point (unless your point was a shameless plug, in which case- kudos). I hear they’ve got Doom running on toasters and refrigerators now too.

My company’s attempts to do anything approaching the level of complexity or visual fidelity that we could get out of the web player have been met with disappointment and frustration. WebGL is simply not ready for prime time beyond simple games and applications (and that includes even the most cutting edge games that came out in 1999).

I think for most of our users, the measure of complexity would primarily be “on parity with WebGL”. Today, there’s many cases where we can’t make that happen, due to limitations as the plugin-less web/browser as a platform.

Even with the same abilities as WebPlayer, WebGL still wouldn’t be as good, because you need a server to host it, right? You can’t just stick it into a dropbox to share with people.

The built product using WebGL consists of a collection of files, just like the Web Player does.

Both of these options require servers to run (that’s how the data gets distributed) but in your case, you are using the Dropbox servers to host your Web Player game.

You could host your WebGL game on Dropbox but you may need to edit the files that Unity builds to refer to the URLs that point t the files that the project needs.

I would, however, suggest getting an AWS account and putting your files in S3. For a few cents per month you can host your files without changing them after Unity builds them.

There should be no problem copying the deployment folder to your dropbox folder and sharing the public url for the the entry html file.

on the last Chrome update, chrome is not highliting NPAPI option when entering that command on the nav bar. And there is a warning prompt that warns the user not to do it… And the prompt says that on chrome 45 that trick wont work either.

They have their own flash implementation to avoid npapi so you should find an agreenent with them. Unity is becoming huge and they know it. I’ve worked with webgl before and due to performance is why Unity was my choice :(

They have their own Flash implementation using PPAPI, but I don’t expect that they will keep that route open longer then they have to. PPAPI essentially shares all the security issues with NPAPI, so I expect it will only be a matter of time until Google will stop supporting this as well – they only reason they can’t do that yet, is because Flash content is still so prevalent on the web (much more so then Unity or any other plugin). But it is declining quickly.

Build times are key for us right now – IL2CPP + emscripten takes 5-8 minutes to build our project. It makes any form of development impossible. It would be great to hear some more info from Unity about general expectations for the true 1.0 version of WebGL publishing. Is there work in the pipeline that should bring the builds to a manageable duration?

Yes, this is a problem, and yes, there is work being done to improve this, both on the IL2CPP side and on the emscripten side (the plan there is to move emscripten to being a native executable completely, as opposed to a collection of native, python and JavaScript code as it is now). This will get build times down, however, I would not expect build times to ever be as low as with the web player, as you will always need to actually build the player JavaScript.

Let’s not be overly dramatic – in no way do 5-8 minute compile times make “any form of development impossible”. Slower, more inconvenient, sure. But 5-8 minutes is pretty normal for mobile developers and always has been, and we’ve got along fine.

Could you develop unity extension for chrome

Chrome extension could do many things that WebGL lacks. Such as networking or accessing folder. I feel somehow you can making unity chrome extension as a center service and let the webGL exported from unity try to install this extension and call it for some functionality like socket

Seem like Firefox able to do so, this would be a way to go over HTML and JS standard for a while

Leave it to web browser developers like Google to remove features BEFORE a suitable replacement exists.

This is yet another fantastic reason why the web should NEVER be considered a software platform. It’s a document platform that’s been hacked all to hell, end of story.

well, webGL does sound great. but i never managed to compile a working build with it.
always got java scripts error so i assume it’s just not ready yet…
hope it will be before google pull the plug from NPAPI for good.

Another useful article concerning WebGL would be helping with support for gzip compression on the files for a variety of server configurations. Each browser requires it’s own set of adjustments to get the exported compressed files to work, so having a rundown of each, with recommendations and caveats, for Apache, Node.js, and other common server configurations.
It may not be possible to provide guidance for every configuration, it would be useful to know when running off virtual hosts and other locations.

Unity should be working with browsers to stop blocking NPAPI instead. WebGL will never be as good as WebPlayer and it will be years before it’s even an acceptable solution.

I can’t agree more.
There’s no real reason for NPAPI deprecation except for Google forcing people to use their own Native Client (NaCL) API.

No reason at all, except it’s an API created by Netscape in the 90s, with serious security holes. Many things in the web use it, which makes the entire internet a less secure place. Deprecating it and moving forward in favor of the new standard is the best option. It will need everyone to take some time to adapt to the new tech, but eventually it’s going to be better than the old stuff.

But the problem is current standard are not cover enough things that NPAPI could do. Before moving forward the standard itself should ready to replace. Your argument is not wrong, but not now

Maybe this is the time to deprecate NPAPI because this forces Unity and Unreal to work with the browser companies to improve WebGL ¿who can improve WebGL? Google, Mozilla and Microsoft, ¿who is forcing this? Google. Or maybe this is random and crappy desition, who knows.

I agree here – the decision to kill NPAPI with all it’s security issues is not a wrong one. The only thing unfortunate is the timing, as we are right now in a situation where we cannot provide an adequate replacement for the technology they killed. However, given current developments in this space, I am confident that in a year or two from now, WebGL will have matured so much, that Unity web content developers will be in a much better position then they ever have been with the web player.

“They will polish WebGL and all will be good” – absolutely wrong! WebGL is based on JavaScript, yeah? Do they expect developers to rewrite their NPAPI plugins (written in their favorite language) to that stupid outdated JavaScript with so fundamental design flaws and dynamic typing? F**k you Google!

Comments are closed.