Why Won't Silverlight Run in Chrome, Edge, or Firefox?

The one-sentence answer

Silverlight was an NPAPI/ActiveX browser plugin, and every current mainstream browser has removed support for that entire class of plugin — so there is nothing for the Silverlight runtime to plug into.

How plugin hosting worked

In the 2000s, browsers exposed plugin interfaces that let separately installed native software draw inside a rectangle on a web page. Flash, Java applets, and Silverlight all worked this way. The browser handed the plugin a region of the page and largely got out of the way: the plugin ran its own runtime, with its own rendering, networking, and security model, as native code on the user's machine.

That architecture is precisely what browser vendors spent the 2010s dismantling. Native plugins ran outside the browser's sandbox and security controls, crashed pages, drained laptop batteries, and required users to keep a separate piece of software patched. One by one, browsers dropped NPAPI and ActiveX hosting. The last mainstream home for Silverlight was Internet Explorer 11, and Microsoft has since retired IE11 as well. Microsoft's own Silverlight end-of-support notice closed the loop from the plugin side.

So when a modern browser hits a Silverlight `<object>` tag, it does not fail to run Silverlight — it no longer has any concept of hosting it. The page typically shows a blank region or an eternal "Install Microsoft Silverlight" badge that installing Silverlight will not fix.

What about Edge's IE mode?

Microsoft Edge includes an IE mode intended as a bridge for organizations with legacy internal sites, described in the IE11 retirement announcement. It re-creates Internet Explorer's rendering behavior for designated sites. IE mode is a managed compatibility tool, not a general escape hatch: it is configured through enterprise policy, it exists to buy time for migrations, and it inherits the fundamental problem that the plugin it would host is unmaintained. Organizations that lean on it should treat it as a countdown clock, not a destination.

What replaced plugins

The capability plugins provided — running fast, rich application code inside a web page — did not go away. It moved inside the browser. Modern browsers ship WebAssembly, a standardized, sandboxed binary format that runs at near-native speed as a first-class part of the web platform. Mozilla's developer documentation is a good introduction to how it works. The crucial difference from the plugin era: WebAssembly needs no separate install, runs under the browser's own security model, and is maintained by the browser vendors themselves as part of the platform.

This is why the practical answer to "how do I make Silverlight run again" is almost always "you don't." The path forward is moving the application to a technology the modern web actually hosts — for .NET codebases, that usually means Blazor, which can run C# in the browser on WebAssembly. See is Blazor the replacement for Silverlight for how that migration looks, and how to inventory a legacy Silverlight app if you are just starting to size up the problem.