Protecting a Blazor WebAssembly app

A Blazor WASM app downloads your compiled .NET assemblies straight into the browser, where anyone can save and decompile them.

Guide 7 min read Updated August 2026

Blazor WebAssembly is the most exposed way to ship .NET code. A desktop app at least requires someone to install it first; a Blazor WASM app hands your compiled assemblies to every visitor automatically, because the browser cannot run them without downloading them.

Anyone can already read your code

Open any Blazor WebAssembly site, open the browser's developer tools, and look at the network requests. You will see your application's .NET assemblies being fetched from the _framework folder. They can be saved with a click.

Those files are ordinary managed .NET assemblies. Drop one into ILSpy and you get back readable C# — your components, your services, your validation logic. This is not a flaw in Blazor; the runtime needs the IL to execute it. It is simply the nature of shipping .NET to a client.

Newer .NET versions package these assemblies in a WebAssembly wrapper rather than serving bare .dll files, which makes them slightly less obvious in the network tab. It is a packaging change, not a protection measure — the managed assembly is still inside, and tooling to unwrap it is readily available.

What this means in practice

Treat a Blazor WASM app as fully public code. That is worth stating plainly, because two mistakes follow from forgetting it:

  • Secrets in client code are published secrets. An API key, a connection string or a signing secret compiled into a Blazor WASM assembly is visible to every visitor. Obfuscation does not change this — string literals are not encrypted, and even if they were, the running app must decrypt them.
  • Client-side authorisation is a UI convenience, not a control. Hiding an admin button in the browser means nothing if the API behind it does not check permissions server-side. A reader of your assemblies can see every endpoint your app knows how to call.
The rule for Blazor WASM: anything that must stay secret belongs on the server, behind an API that authorises every request. Obfuscation protects your implementation, never your secrets.

What obfuscation does help with

Within those limits, renaming is genuinely useful here — arguably more so than for a desktop app, precisely because the audience is so much wider:

  • Your business logic — pricing rules, scoring, workflow decisions implemented client-side — stops being casually readable.
  • Component and service names no longer map out your application's structure for anyone poking around.
  • Internal names stop leaking unreleased features, internal project names, or the shape of the backend they talk to.

Fitting it into a Blazor publish

The important detail is ordering. Blazor's publish step collects your assemblies, packages them for the browser, and generates an integrity manifest so the runtime can verify what it downloads. Rewriting an assembly after that step will not match the manifest.

So obfuscate the compiled assembly before the Blazor publish packaging runs:

  1. Build your Blazor WASM project in Release.
  2. Obfuscate your own application assembly (and any shared project you ship with it).
  3. Publish, so packaging and the integrity manifest are generated from the protected files.
  4. Run the published app and check it in a browser before deploying.

Obfuscate only assemblies you own. Framework and third-party assemblies are shipped as-is, and renaming inside them causes problems without buying you anything.

A practical caveat. This tool takes one assembly per request, and a Blazor app ships several. Batch mode on Pro handles up to 20 in one pass, and the API is the sane way to do this repeatedly rather than by hand on every release.

What will break, and what to test

Blazor leans on reflection more than a typical .NET app, so the usual failure modes matter more here:

  • JSON serialization across every API call. Property names become your wire contract — pin them with [JsonPropertyName].
  • Dependency injection registered by convention rather than explicitly.
  • Component parameter binding and anything resolved by name at runtime.
  • Routing, if any of it is derived from type names.

Before deploying, load the published app in a browser and confirm:

  • It starts without console errors and the first page renders.
  • A round-trip API call sends and receives the JSON you expect.
  • Navigation between routes works.
  • Forms validate and submit.

The honest summary

Blazor WebAssembly publishes your code by design, and nothing changes that. What obfuscation changes is whether a visitor who opens the network tab out of curiosity finds readable business logic or a wall of meaningless names.

Combine it with the discipline the platform demands anyway: secrets on the server, authorisation on the server, and the client treated as untrusted. If you want a sense of how far that gets you, what obfuscation actually protects against is the realistic version.

Try it on your own assembly

Upload a DLL or EXE and download the obfuscated result. Free, no signup, nothing stored.

Obfuscate a file See Pro features
Guide How to obfuscate a .NET DLL or EXE A step-by-step walkthrough of obfuscating a compiled .NET assembly, what changes in the output, and how to verify the result still runs. 6 min read Guide Obfuscating .NET builds in CI/CD Wire the obfuscation API into GitHub Actions, Azure Pipelines or a local build script so every release artifact is protected automatically. 8 min read Guide Obfuscation and reflection: what breaks and why Renaming is safe until something looks up a member by name. Serialization, DI containers and XAML are the usual suspects — here is how to avoid each trap. 8 min read