The Blazor Auto Render Mode Explained (Finally!)

How Blazor secretly switches between Server and WebAssembly, and why that’s actually genius.

Patrick God

Oct 21, 2025

You know what still confuses a lot of developers?

Blazor’s Auto Render Mode.

Even now with .NET 10 RC2, it’s still one of those features that makes people scratch their heads.

So today, let’s fix that once and for all.

I’ll explain how the Auto Render Mode works in Blazor Web Apps, why it exists, and when you should use it.

And to make this more fun, let’s imagine we’re running a fantasy shop, selling swords, potions, and magical trinkets.

Because Blazor’s render modes, they’re like the different ways your customers can interact with your shop, either in person, online, or both.

The Blazor Kingdom: Server vs. WebAssembly

Imagine you own the Blazor Emporium, a magic shop where customers can:

Visit your physical store (like Blazor Server)
Or browse your online catalog (like Blazor WebAssembly)

🏰 Blazor Server

This is your local shop.

Customers walk in, talk to your enchanted assistant (the server), and every time they do something, like buy a potion, your assistant handles it right away.

Super fast on the first visit
No long loading times
But if the magical connection (SignalR) breaks — poof! — your shop stops responding.

🌎 Blazor WebAssembly

Now imagine you ship your shop to the customer’s home.

They can browse, buy, and interact without needing to talk to your server all the time.

Works offline once loaded
Feels smooth after the first load
But the first time? It’s like sending a full caravan of crates, boxes, and magic scrolls. Takes time.

Then Came the “Auto” Mode

Microsoft saw both options and thought:

“Why not let the customer start in the shop, and then later set up their own mini-shop at home?”

That’s exactly what Interactive Auto Render Mode does.

Auto mode starts with Blazor Server, then switches to Blazor WebAssembly once everything’s ready.

So the first time a user visits your site, it feels fast, because it’s running on the server.

But while they’re browsing, Blazor quietly downloads all the WebAssembly bits in the background.

Next time they visit?

It runs entirely in their browser, lightning fast, with no server connection needed.

Setting It Up (Step by Step)

Let’s open Visual Studio (I’m using the 2026 “Insiders” edition with .NET 10 RC1. Fancy, I know).

When you create a new Blazor Web App, you’ll see a few important settings:

Interactive Render Mode: set this to Auto
Interactivity Location: choose Per Page/Component

That means every page or component can decide how it should render.

Here’s what that looks like:

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

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

These lines tell Blazor:

“Hey, this app can do both, Server and WebAssembly.”

When you set the render mode of a component or page to InteractiveAuto, Blazor will handle switching for you.

Where It All Starts: Server First

When a user first visits your page, Blazor starts in Server mode.

You’ll see something like this in the browser console:

Information: WebSocket connected

That means you’re in Blazor Server territory, real-time connection between client and server.

But here’s the magic trick:

While you’re interacting with the app, Blazor is downloading the WebAssembly resources quietly in the background.

Then It Switches: WebAssembly Kicks In

Next time you reload the page, check your console again.
You’ll notice, no WebSocket connection this time.

That means Blazor is now running fully on the client.

All your .dlls and resources are already there, so the app loads instantly.

The Auto Render Mode gives you the best of both worlds, speed on first load, and independence on repeat visits.

The Confusing Part: Pre-Rendering

Now here’s where many developers (including me, at first) get tripped up.

Pre-rendering means Blazor renders your page on the server first, even before interactivity starts.

Why?

Because it gives users a super-fast first impression. They see content right away, even if interactivity (buttons, forms, etc.) isn’t ready yet.

But the tricky part is this:

Even if you think you’re in WebAssembly mode, your code still runs on the server first during pre-rendering.

So when you try to fetch data, it might do it twice: once on the server (for pre-rendering), and again on the client (after hydration).

Example: Weather Page

Let’s say you have a weather page:

@page “/weather”
@rendermode InteractiveAuto

@code {
    private WeatherForecast[]? forecasts;

    protected override async Task OnInitializedAsync()
    {
        forecasts = await ForecastService.GetForecastAsync();
    }
}

When pre-rendering is enabled, Blazor does this:

Fetches the data on the server first.
Then, after hydration, runs the same code again on the client.

That’s why you sometimes see a quick “flash”, first old data, then new data.

Disabling Pre-Rendering

If that flash bothers you, you can disable pre-rendering:

@rendermode @(new InteractiveAutoRenderMode(false))

Now your app won’t pre-render on the server.
It’ll wait until the client is ready, and then run entirely on the browser side.

You’ll see a short “Loading…” message instead of flickering data.

The Persistent State Fix

There’s another approach that keeps the benefits of pre-rendering without losing your data.

You can use the [PersistentState] attribute to make your data “survive” the switch from server to client.

Here’s a simple example:

@page “/weather”
@rendermode InteractiveAuto
@inject IWeatherForecastService ForecastService

@code {
    [PersistentState]
    public WeatherForecast[]? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (Forecasts is null)
        {
            Forecasts = await ForecastService.GetForecastAsync();
        }
    }
}

Now the weather data fetched during pre-rendering gets handed off to the client after hydration.

No flash, no double fetching.

When Things Get Tricky: Database Access

Now imagine our Blazor shop needs to fetch real data, say, from a database.

Maybe we want to list available enchanted swords in stock.

When you use Auto Mode, remember this rule:

The app starts on the server, then moves to the client.

So if your code fetches data from a database directly with EF Core, that works fine in Server mode…

But not once you’re running in WebAssembly, because there’s no direct database access from the browser, you have two main options:

Option 1: Use an API Endpoint

In your Server project, create a controller or minimal API:

app.MapGet(”/api/swords”, async (SwordDbContext db) =>
    await db.Swords.ToListAsync());

Then call it from your Blazor component using HttpClient:

var swords = await Http.GetFromJsonAsync<List<Sword>>(”/api/swords”);

This works perfectly in WebAssembly mode.

But what about the Server part of Auto Mode?

Simple, you can register HttpClient on the server too, and make it call your own endpoint.

It’s a little weird (yes, you’re calling yourself), but it keeps your logic consistent.

Option 2: Shared Service Layer

If you want to be more elegant, you can create a Shared project:

Define an interface, e.g. IInventoryService
Add a project reference to both your Client and Server projects

Then implement the interface differently in each place:

On the Server, it uses EF Core directly
On the Client, it makes an API call

// Shared
public interface IInventoryService
{
    Task<List<Sword>> GetAllSwordsAsync();
}

// Server
public class ServerInventoryService(SwordDbContext db) : IInventoryService
{
    public async Task<List<Sword>> GetAllSwordsAsync() =>
        await db.Swords.ToListAsync();
}

// Client
public class ClientInventoryService(HttpClient http) : IInventoryService
{
    public async Task<List<Sword>> GetAllSwordsAsync() =>
        await http.GetFromJsonAsync<List<Sword>>(”/api/swords”)
            ?? new List<Sword>();
}

This setup works beautifully with Auto Mode. No duplication, no confusion.

Things to Remember

Auto Mode starts on the server, then moves to the client.
Pre-rendering happens on the server, no matter what.
You can disable pre-rendering if you want full control.
Use [PersistentState] in .NET 10 to keep your data during hydration.
For database access, either use API calls or shared interfaces.

Think of Blazor Auto Mode as your magic teleportation system.
It starts in the castle (server), but then teaches your customers to run their own mini-shops at home (client).
You just have to make sure the spell books (data) travel with them safely. That’s your pre-rendering and state persistence at work.

Wrapping It Up

So that’s Blazor Auto Render Mode in a nutshell.

It’s not really a new render mode, it’s more like a clever sequence:

Start fast on the server, then stay fast on the client.

If you understand how pre-rendering, hydration, and state persistence fit together, you’ll never be confused by Auto Mode again (maybe).

Remember: Blazor isn’t magic, but once you understand the spells, it sure feels like it.

P.S. You can watch the full video tutorial on YouTube here 👇

P.P.S. You can find the full source code for this tutorial on GitHub.