Is There a Replacement for Silverlight?
Yes, but not a drop-in one. Nothing installs in a browser today and runs old Silverlight apps unchanged; instead, Microsoft points web-facing Silverlight workloads toward Blazor, desktop-style workloads toward WPF, and the browser itself now offers WebAssembly as the standards-based successor to the plugin model Silverlight depended on. Which replacement fits depends on what your Silverlight app actually was.
Why there's no one-to-one substitute
Silverlight bundled several things into one plugin: a .NET runtime inside the browser, a XAML-based UI layer, media playback, and out-of-browser desktop installs. No single modern product covers all of that, because browsers deliberately stopped supporting the plugin architecture that made the bundle possible. The modern answer splits by scenario.
Blazor: the closest spiritual successor for web apps
For a Silverlight app whose job was to be a rich app inside a browser tab, Blazor is Microsoft's current answer: you write C# and .NET, and it runs in the browser without any plugin — either on the server with a thin client connection, or directly in the browser via WebAssembly. Microsoft documents both hosting models, and the choice between them is one of the first real decisions in a migration; we compare them in Blazor Server vs. Blazor WebAssembly.
What carries over: C#, .NET libraries (with porting work), your team's general architecture instincts. What doesn't: XAML markup and the Silverlight control set — Blazor components are built with Razor syntax over HTML and CSS. Our deeper look at whether Blazor is the Silverlight replacement covers where the analogy holds and where it breaks.
WPF: when the app never needed a browser
Plenty of Silverlight line-of-business apps ran inside a browser only because that made deployment easy in 2010. If every user is on a managed Windows machine, WPF is often the shortest path: it is a XAML framework, so markup, data binding patterns, and control concepts translate far more directly than they do to any web stack. The trade-off is that you give up the browser entirely. We walk through the decision in when WPF makes sense for a former Silverlight app.
WebAssembly and standard web tech: the platform-level replacement
At the platform level, the thing that actually replaced plugins is the modern web itself. WebAssembly — a W3C-standardized runtime built into every major browser — lets compiled code run at near-native speed inside the browser's sandbox, which is the legitimate, secure version of what NPAPI plugins did unsafely. Mozilla's developer documentation is a good technical starting point, and our plain-English WebAssembly explainer covers the concept without the jargon. If your team is willing to leave .NET for the UI layer, a conventional rebuild on HTML, CSS, and JavaScript/TypeScript is also a fully valid replacement — arguably the most future-proof one.
How to choose
- Browser delivery required, team knows .NET → Blazor, then choose a hosting model.
- Windows-only users, heavy XAML investment → WPF.
- Public-facing product, long horizon, mixed team → standard web stack, with WebAssembly for any compute-heavy parts.
- Not sure what the app even contains → inventory first; the right target often falls out of what you find.
The honest summary: Silverlight has no successor, but every job Silverlight did now has one.