Blazor Server vs WebAssembly vs Auto: which one for a business application?

Every Blazor project starts with the same decision, and it is easy to get wrong: should the application run on the server or in the browser? Choose badly, and a year later you are buying bigger servers because every user holds memory, or explaining to users why the first load takes so long.

The short answer: since .NET 8 you no longer choose one mode for the whole application, but for each page. For most business applications the right mix is simple: plain server rendering for public pages, Interactive Server for internal screens, and WebAssembly only where it clearly pays off.

The four modes in plain words

Mode	Where the code runs	What the user gets
Static server rendering	On the server, once per request	An ordinary fast HTML page, forms work, but no live interactivity
Interactive Server	On the server, over a constant connection	Instant start, every click goes to the server and back
Interactive WebAssembly	In the user’s browser	A larger first download, then everything runs locally, even offline
Interactive Auto	First on the server, then in the browser	Starts like Server, and on later visits, once the files are downloaded, switches to WebAssembly

Compared by what matters to the business

	Interactive Server	WebAssembly
First load	Fast	Slower the first time, then cached
Hundreds of users at once	No problem	No problem
Tens of thousands at once	Needs planning: memory per user, more servers or Azure SignalR Service	Barely touches the server
Weak or unstable connection	Every click waits for the network, and a dropped connection means reconnecting	Works locally, only data calls wait
Offline work	Not possible	Possible
Code and business rules	Stay on the server	Are downloaded to the browser, so nothing secret may be in them
Access to the database and services	Directly	Only through an API
Server cost	Grows with the number of users working at the same time	Mostly the cost of the API

The key difference is not speed, but where the code lives. With Interactive Server, the screen calls your services and the database directly, and nothing leaves the server. With WebAssembly, the application in the browser is effectively a public client: everything it knows, a curious user can see, and every piece of data has to come through an API that checks permissions.

The real answer: per page

In a Blazor Web App, each page or component declares its own mode. The application is prepared for both interactive modes once, in Program.cs:

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Client._Imports).Assembly);

After that, a single line on the page decides:

@page "/orders"
@rendermode InteractiveServer

@page "/field/inspection"
@rendermode InteractiveWebAssembly

A page without @rendermode is rendered statically on the server, which is exactly what a public page or a simple form needs. Components that run in WebAssembly live in a separate client project, which the Blazor Web App template creates for you.

A typical mix for a business application

• Public pages, sign-in, simple forms: static server rendering. Fast, good for Google, no constant connection.
• Internal screens, administration, reports: Interactive Server. Direct access to services, nothing leaves the server, and for a few hundred employees the server load is modest.
• Screens for work in the field or on weak connections: WebAssembly. Worth the extra API only where the connection really is a problem.

For a typical internal application, that means most screens use Interactive Server, and WebAssembly is the exception, not the default.

The traps

• Auto looks like the best of both worlds, but costs the most. The same component has to work on the server and in the browser, so it cannot call services directly and needs an API for everything. Choose it when you really need both behaviours, not as a safe default.
• Interactive Server holds state per user. Every open tab keeps memory on the server until the user leaves. Components that load huge lists into memory multiply that by every user. The article on slow Blazor applications shows how to keep it under control.
• With WebAssembly, the browser is not yours. Connection strings, API keys and pricing rules must not be in the client project, and every API call has to check permissions on the server again. The full list is in the Blazor security checklist.
• Prerendering loads data twice if you do not handle it: once on the server for the first HTML, and again when the page becomes interactive. In .NET 10 the [PersistentState] attribute solves this.

Five questions before you decide

1. How many users will work at the same time, and where are they: in the office or in the field?
2. How good is their connection, and do they need to work offline?
3. Does the screen need direct access to services and the database, or do you already have an API?
4. Is there anything in the screen’s logic that users must not see?
5. Does the page need to be found on Google?

For most internal screens, the answers lead to Interactive Server. For public pages, to static rendering. WebAssembly wins where the connection or offline work decides.

If you are still deciding whether to build in Blazor at all, see Is Blazor still relevant in 2026? and Blazor vs React for business applications. A short overview of which mode fits which screen is also on the Blazor page.

How we work

ProCoding is a .NET studio from Split, Croatia, and we have been shipping Blazor to production since 2020. We help you choose the mode per screen before the first line of code, and fix applications where the choice turned out wrong. The first step is a free 30-minute call.

Sources

• ASP.NET Core Blazor render modes, Microsoft Learn
• ASP.NET Core Blazor hosting models, Microsoft Learn
• Prerendered state persistence, Microsoft Learn
• Azure SignalR Service, Microsoft Learn