Compile C# to WebAssembly with NetWasm.

What you get

A normal NetWasm project uses the .NET CLI. You write C#, restore NuGet packages, build, run tests, and publish using familiar commands. The difference is the target platform and runtime contract.

• Roslyn compiles C# to ordinary CIL.
• NetWasm performs closed-world analysis and compiles reachable CIL to Wasm.
• Only reachable code, data, generics, runtime support, and host imports are retained.
• The default executable output is a standalone wasm32 WASI Preview 2 component.

Requirements

Install .NET SDK 10.0.303 or newer. Use the .NET 11 SDK when your source uses C# 15. NetWasm supports Linux x64 and ARM64, macOS ARM64, and Windows x64 and ARM64 as development hosts.

The NetWasm packages restore their pinned build tools through NuGet. An ordinary application does not require a separate Emscripten, Node.js, Python, Git, LLVM, or Binaryen installation.

Compile C# to Wasm

Install the project templates, create an application, and run it:

$ dotnet new install NetWasm.Templates
$ dotnet new netwasm-app -n HelloNetWasm
$ cd HelloNetWasm
$ dotnet run
42

Publish an optimized component:

$ dotnet publish -c Release -o publish/local

The resulting component is publish/local/HelloNetWasm.wasm.

Run the component

Run the published component with a compatible WASI Preview 2 host. For example, with Wasmtime:

$ wasmtime run publish/local/HelloNetWasm.wasm
42

The deployment machine needs a compatible WebAssembly host. It does not need .NET or NetWasm installed.

Compile C# to WebAssembly in your browser

The NetWasm Playground runs the compiler locally in the browser. You can edit C#, compile it, run the result, inspect diagnostics, compare optimization settings, and download the component without sending the source to a compilation server.

Browser deployment uses a JavaScript host adapter around the same compiled program. NetWasm is not Blazor and does not require a Blazor UI framework.

How the C# to WebAssembly pipeline works

1. C# to CIL: Roslyn handles C# syntax, binding, diagnostics, and standard CIL generation.
2. Closed-world analysis: NetWasm starts from the application entry points and follows reachable managed code.
3. CIL to Wasm: The compiler specializes concrete generics, lays out managed data, and emits WebAssembly instructions.
4. Runtime linking: Required CoreLib and runtime support are linked into the program. Unreachable support stays out.
5. Component packaging: The default publish path wraps the core module as a WASI Preview 2 component.

This is ahead-of-time compilation. NetWasm does not interpret CIL at runtime and does not embed a general desktop CLR in the output.

Current limits

NetWasm is pre-1.0 and deliberately implements a smaller .NET profile. Runtime reflection, dynamic, runtime assembly loading, and managed threading are outside that profile. Existing NuGet packages work only when their reachable APIs and runtime assumptions fit the supported surface.

See the member-level support inventory and current limitations before porting a substantial application.

Common questions

Does C# compile directly to WebAssembly?

Roslyn first compiles C# to CIL. NetWasm then compiles the reachable CIL and runtime support to WebAssembly. The complete process is ahead of time and produces Wasm instructions rather than interpreted CIL.

Does the output require .NET?

No desktop .NET runtime is required at deployment. The Wasm artifact contains the runtime support selected for the application. A compatible WebAssembly host is still required.

Is NetWasm the same as Blazor WebAssembly?

No. NetWasm is a compiler, runtime, CoreLib, SDK, and target profile. It can publish standalone WASI components and browser-hosted programs without requiring Blazor.

Can I use existing .NET libraries?

Libraries can target netwasm0.1 alongside desktop .NET. Compatibility depends on the reachable API surface, not merely on whether a package targets another .NET framework. NetWasm also publishes focused ports for common libraries.