Microsoft · Technology
Blazor
Blazor is Microsoft's framework for building interactive web UI out of reusable components written in C# and Razor instead of JavaScript. The same component runs three ways — on a server, inside the browser on WebAssembly, or natively in a desktop or mobile app — and since .NET 8 you pick the model per component. It ships inside ASP.NET Core / .NET.
Architecture current as of .NET 10 (LTS, November 2025) · June 2026
What it is
The unit of a Blazor app is a Razor component — a .razor file that mixes C# and HTML markup and compiles to a .NET class. Components nest, take parameters, hold state, and handle events, the way components do in React or Vue — except the logic is C#, not JavaScript, and it runs on the .NET runtime. A page, a dialog, a data-entry form: each is a component.
What makes Blazor unusual is that the same component runs unchanged across very different execution environments. Where the C# actually runs — and how its UI updates reach the browser — is the hosting model, and that's the first thing to understand about the framework. I keep this page static and sourced to Microsoft's own documentation; the diagrams below are the architecture, not marketing.
Blazor is built on ASP.NET Core, you write it in C#, and it's Microsoft's answer for teams that want to build a browser UI without leaving the .NET stack — an alternative to the JavaScript single-page-app frameworks for shops that are already C#-first on the back end.
The architecture · hosting models
The one idea the next diagram teaches: the component is identical in all three columns. Only where the .NET code executes and how its updates reach the screen change.
Read this diagram as text
Blazor Server: the same Razor component executes on the server inside the .NET runtime (CLR); UI events and DOM updates travel over a persistent SignalR WebSocket connection (the per-client server-side state is a circuit); the client is a thin browser. Instant first load, but it needs a live connection and is sensitive to latency.
Blazor WebAssembly: the same component executes client-side, in the browser, on a WebAssembly build of the .NET runtime that downloads with the app; UI updates happen in-process with no server round-trip; the client is the browser plus the downloaded runtime. Runs offline after load, heavier initial download.
Blazor Hybrid: the same component executes natively in a .NET process (a .NET MAUI / WPF / Windows Forms app) and renders to an embedded WebView over a local interop channel; the client is a native app shell. Web UI, native app, no WebAssembly involved.
Components run on the server inside an ASP.NET Core app. The browser holds almost nothing; when the user clicks, the event is sent to the server, the component re-renders there, and only the resulting DOM diff is pushed back over a SignalR connection (WebSockets). The per-client server-side state is called a circuit; circuits survive brief network interruptions and reconnects. The upside is a tiny download and instant startup; the cost is a permanent live connection per user and sensitivity to round-trip latency.
Components, their dependencies, and a WebAssembly build of the .NET runtime download to the browser and run client-side, directly on the browser's UI thread. There's no per-interaction server round-trip, and the app keeps working offline once loaded. The trade is the initial payload: the runtime and assemblies have to come down first (Blazor trims unused code, compresses responses, and caches the runtime to soften this). The in-browser runtime is the Mono .NET runtime compiled to WebAssembly — an open web standard that runs without any browser plugin, which is the structural difference from Silverlight a decade earlier.
Components run natively inside a .NET MAUI, WPF, or Windows Forms app and render their web UI into an embedded WebView control over a local interop channel. No WebAssembly, no SignalR — the .NET code is just part of the native process. It's how a team reuses the same Razor components across a web app and a desktop or mobile app.
The architecture · render modes (.NET 8+)
Before .NET 8 you chose Server or WebAssembly for the whole project. The unified Blazor Web App replaced that with a render mode picked per component — you can mix all four in one app, even on one page.
Read this diagram as text
A single Blazor Web App (the unified model introduced in .NET 8) holds components that each declare their own render mode:
Static SSR — plain server-rendered HTML with no interactivity, for content and SEO-focused pages. Interactive Server — interactivity delivered over a SignalR circuit, for data-driven dashboards and apps that rely on centralized state. Interactive WebAssembly — interactivity running client-side via WebAssembly, for rich, offline-capable clients. Interactive Auto — starts on the server for a fast first paint, then transparently switches that component to WebAssembly once the runtime has downloaded and cached.
The point: render mode is a per-component choice, so Static SSR, Interactive Server, and Interactive WebAssembly can all coexist in the same app and even on the same page.
The architecture · what sits on what
The vertical companion to the hosting-models comparison: your components sit on the Blazor framework, which sits on the .NET runtime, which executes on one of three substrates and paints to the browser DOM or a native WebView.
Read this diagram as text
Top to bottom: Razor components (your UI, C# plus markup) sit on the Blazor framework (component model, rendering, routing, built on ASP.NET Core), which sits on the .NET runtime. The runtime executes on one of three substrates — the server CLR, the WebAssembly runtime (the Mono runtime, running in the browser), or native .NET (desktop/mobile) — and the result paints to the browser DOM or a native WebView. The top three layers are identical across hosting models; the hosting model is just which substrate (layer 4) runs underneath.
A short history
Blazor began as an experiment. In 2017, Microsoft engineer Steve Sanderson demonstrated an interactive .NET app running in the browser on WebAssembly — using a small third-party runtime called DotNetAnywhere — at the NDC Oslo conference. The reception turned the prototype into a product. Blazor Server shipped first, in 2019 with .NET Core 3.0, driving the browser over a WebSocket connection. Blazor WebAssembly followed in May 2020, this time on the Mono .NET runtime compiled to WebAssembly.
The pivotal change came with .NET 8 in November 2023, which unified the two into a single Blazor Web App and made the render mode a per-component choice rather than a project-wide one. .NET 9 (2024) refined it, and .NET 10 — the current Long-Term Support release, out November 2025 — brought, by Microsoft's own framing, the broadest set of Blazor enhancements of any release, including improvements to prerendering. Because the architecture genuinely shifts with the annual November .NET release, this page carries an as-of stamp and gets re-checked against Microsoft's docs on a schedule.
Is this Silverlight again? It's a fair question — Microsoft shipped a browser-plugin runtime once before, and retired it. The structural answer is that Blazor WebAssembly runs on the open WebAssembly web standard, supported natively by browsers with no plugin to install or maintain. That's the difference that matters.
Where it fits — and the trade-offs
Blazor is the natural choice for a team that's already C#-first and wants to build a browser UI without standing up a separate JavaScript front-end stack — line-of-business apps, internal tools, and dashboards where the back end is already .NET. Sharing model and validation code between the server and the UI, in one language, is the recurring reason teams reach for it.
The honest trade-offs: WebAssembly carries an initial-download cost — the runtime and assemblies have to reach the browser before the app is interactive — which is why Auto mode and trimming exist. Server needs a persistent connection and adds round-trip latency to every interaction, and it consumes server memory per active circuit. And the component and library ecosystem, while solid, is smaller than React's or Vue's — you'll find fewer ready-made components and answers. None of these is disqualifying; all of them are worth knowing before you commit.
Related on this site
Sources & method
I keep this page static and sourced to Microsoft's own documentation, re-checked against the current .NET release. Primary sources: the ASP.NET Core Blazor hosting models and render modes guides on Microsoft Learn, the dotnet/aspnetcore repository, and the annual .NET DevBlogs release announcements. Architecture described as of .NET 10 (LTS, November 2025); last reviewed June 2026. Blazor's render-mode model changes with the annual November .NET release, so verify against the current docs before acting on anything dated.