We believe app development should feel INSTANT. Meet XAML.io. VB6 feel. Built for today.

OpenSilver is not an emulator, a wrapper, or an Electron-style bundled browser. It is a complete reimplementation of the WPF/Silverlight API from scratch, using modern .NET, WebAssembly, and the browser's DOM. On the Web, your C# code compiles to WebAssembly. Unlike canvas-based rendering approaches, XAML is rendered at runtime using real HTML elements: TextBox becomes <textarea>, MediaElement becomes <video>, PasswordBox becomes <input type="password">, Image becomes <img>, and so on. This unlocks native browser behaviors like Ctrl F search, text selection (to copy text), screen readers, SEO indexing, browser translation, mobile long-press, UI automated testing, and accessibility compliance. The compiled app is a set of static files (WebAssembly, JS, index.html...) that can be hosted anywhere: Azure, AWS, GitHub Pages, or any basic web server. No special server technology is required. On desktop and mobile (via MAUI-OpenSilver Hybrid or Photino), the UI is still rendered as HTML/CSS, but C# runs as native .NET instead of WebAssembly. This preserves full compatibility with JS libraries and Blazor components (because the UI is still HTML/CSS), while adding native performance and direct access to platform APIs (because the runtime is native .NET).

Our browser-based .NET IDE (@xaml_io) now has code sharing and NuGet packages

WPF is the best UI frameworks ever created. We think it deserves to be cross-platform, so more developers can build great apps with it.

WPF got the developer experience right. The web got everything else right. OpenSilver is the first UI framework that combines both. Write in WPF, ship real HTML DOM, not pixels on a canvas, and get accessibility, SEO, Ctrl F, text selection, browser translation, mobile interactions, browser extensions, screen readers, and more. Try it in seconds at XAML.io. No setup. No signup.

OpenSilver is becoming the Web-native WPF. New this week: WPF Triggers support! Available now in the pre-release NuGet, and coming soon to our @xaml_io .NET browser IDE with XAML designer.

Everyone: "XAML is dead, just learn Blazor" Us: "What if you could use both? In the same file?" OpenSilver 3.3 just shipped. → Blazor components inside XAML → One codebase, six platforms → Free & open-source Sometimes the best migration is no migration.

🚀 Auto-completion (IntelliSense) is coming soon to XAML.io, the free online XAML designer. Stay tuned!

Publishing an OpenSilver app with AOT can result in up to 6× better performance.

change anything in context with our ui designer

Many people still think OpenSilver is an emulator or wrapper around Silverlight. It is not. We did not inherit any Silverlight code. Silverlight was closed source. We reimplemented the Silverlight/WPF public API from scratch, using modern .NET, WebAssembly, and the browser’s DOM. Why does this matter to WPF developers? Because Silverlight was a backward-compatible subset of WPF. Same namespaces, same XAML, same patterns. This means what began as a Silverlight migration path has naturally evolved into a realistic way to bring WPF-style applications to the web using C#, XAML, and MVVM, without rewriting everything in JavaScript. And here is what most people do not know: OpenSilver does not render everything in a canvas. We render XAML using real HTML elements: • TextBox → <div contenteditable="true"> • MediaElement → <video> • Hyperlink → <a href> • WebBrowser control → <iframe> Why is that a big deal? Because rendering to the DOM unlocks native browser behaviors: Ctrl F, text selection, screen readers, right click on links, SEO, browser translation, copy and paste, mobile long-press, browser extensions, and regulatory accessibility compliance. You cannot get any of that in a giant canvas rendering model. This is not just “bringing Silverlight to the web”. This is bringing WPF-style architecture to the web, in a truly web-native way. That is why many enterprise teams are migrating, not rewriting.

We're working to bring MAUI syntax to the web through OpenSilver. Stay tuned!

Should OpenSilver evolve to support MAUI-style XAML so you can share UI code between MAUI apps (mobile/desktop) and OpenSilver (Web)?

Which upcoming XAML.io feature are you most excited about?

Userware isn’t just behind OpenSilver — we build AR/VR too. Here are 5 highlights

Most browser IDEs fake it: the build actually happens on a remote server. XAML.io is different: it compiles .NET GUI apps right in your browser via WebAssembly. No backend at all (except for saving to the cloud or optional AI), which makes it ridiculously scalable.

A sneak peek of the C#/XAML RadTileList control from Telerik UI, recompiled with OpenSilver to run beautifully on modern browsers using WebAssembly.

Here’s a sneak peek of the C#/XAML RadDocking control from Telerik UI, recompiled with OpenSilver to run beautifully on modern browsers using WebAssembly.

👇The C#/XAML-based Telerik RadGanttView, recompiled with OpenSilver to run smoothly in modern browsers via WebAssembly. See it in action in a real customer app: pod-demo.azurewebsites.net/?… Contact us for fast, seamless WPF/Silverlight migrations. Our team has ported 1M lines apps.

One of the core design principles of XAML.io is developer control. Every project can be downloaded as a standard Visual Studio solution, and the underlying runtime (@OpenSilverTeam) is fully open-source. This means you can start quickly online, then continue locally at any time — without being tied to a proprietary format or service. Think of XAML.io as a frictionless on-ramp to .NET development, not a walled garden.