.NET obfuscator

Inspect a real before-and-after DLL with ILSpy and compare 2,003 runtime results. The downloadable synthetic sample shows what changes and what remains readable.

Why .NET code needs obfuscating

.NET languages — C#, VB.NET, F# — do not compile to opaque machine code. They compile to IL (Intermediate Language) carried alongside complete metadata: the name of every namespace, type, method, property and field. That metadata is what lets the runtime do reflection and late binding, but it also means a decompiler like ILSpy, dnSpy or dotPeek can turn a shipped assembly back into near-original C# — comments gone, but names, structure and logic all intact. Anyone you hand a .dll or .exe to can read it.

A .NET obfuscator rewrites that assembly so the decompiled result is no longer a gift. At minimum it renames eligible symbols; the deeper layers encrypt strings and rearrange control flow so even the logic is hard to follow. The aim is to preserve behavior while changing its representation. Validate that on the application and its dependencies before release.

How to obfuscate a .NET assembly

1. Build your project in Release so you protect what you actually ship.
2. Find the output — bin/Release/net8.0/YourApp.dll (or .exe).
3. Upload it on the home page. The protected copy is returned in the response. Temporary request buffers are released when the request ends.
4. Download YourApp.obfuscated.dll — a distinct name so it can never overwrite your original — and run your tests against it before shipping.

No install, no config file, no build-pipeline step. If you would rather protect assemblies from CI, the HTTP API does the same thing from a build agent.

A .NET library replacement test with an unchanged consumer

Our downloadable example consists of two separately compiled .NET 8 assemblies: InvoiceLibrary.dll and InvoiceConsumer.dll. The consumer calls a public interface, serializes an invoice, handles an event and checks an exception. This is our own reproducible sample, not a customer success claim.

1. Publish the consumer in Release against the original library.
2. Send only InvoiceLibrary.dll to the production Free obfuscation endpoint.
3. Create a second copy of the published folder. Replace its library with the protected DLL under the expected name InvoiceLibrary.dll. Keep the consumer, dependency manifest and runtime configuration unchanged.
4. Run the same compiled consumer in both folders and compare results.

On October 23, 2026, the consumer's SHA256 was identical in both folders and all ten checks passed with identical output. ILSpy confirmed that _calculationCount and RoundMoney were renamed while the public contract survived. The C# walkthrough shows the code and the invoice values.

Download the .NET compatibility example Inspect hashes and results

This verifies one framework-dependent .NET 8 library and consumer. It does not certify every framework, WPF/XAML app, plugin loader, signed assembly or publish mode. Keep your original deployment and test the protected artifact with its real dependencies.

Which build output should you upload?

• Managed .NET library: upload the DLL; preserve its public contract for other assemblies.
• Modern .NET application: the managed application commonly resides in a DLL beside a native apphost EXE. Upload the managed DLL, then test it in a complete published folder. An application DLL can have an entry point despite its extension.
• Native C/C++ or NativeAOT output: it is native machine code, not the managed input this service expects.
• Single-file or specialized deployments: do not assume an outer executable is a rewritable managed assembly. Validate your build and packaging workflow separately; this sample does not cover those modes.

The protection layers, honestly

Obfuscation is not one switch. It is a stack of layers, each raising the cost of understanding the code a little differently. Here is what each one actually does — and where it sits on the free and Pro tiers.

• Symbol renaming (free). ValidateLicenseKey becomes @a. Eligible private and internal members are renamed, with compatibility exclusions. Public renaming is opt-in for applications; libraries keep their public API so existing callers can bind.
• Block ILDasm (free). Adds the legacy SuppressIldasm attribute. This does not stop modern tools such as ILSpy from decompiling the output.
• String encryption (Pro). Literal strings — messages, keys of algorithms, URLs — are readable in a decompiler by default. String encryption stores them encrypted and decrypts at runtime, so a casual reader no longer greps your binary for interesting text.
• Control-flow obfuscation (Pro). Rewrites methods into an equivalent but reordered basic-block shape. Methods with exception handlers are skipped by this pass; a decompiler may still simplify some transformed methods.
• Reference proxying (Pro). Routes eligible external static calls through generated forwarding methods. These proxies add indirection; an analyst can still inspect their targets.
• Method virtualization (Pro). Marked, supported methods are turned into bytecode for a small interpreter embedded in your assembly. A decompiler sees the interpreter, not your algorithm. It costs runtime performance and output size, so it is opt-in per method rather than applied wholesale.

What .NET obfuscation protects — and what it does not

Being straight about the limits matters more than overselling. Obfuscation raises the cost of reverse engineering; it does not make code impossible to understand, and it is not a substitute for the things it is often mistaken for.

• It does not stop decompilation. The runtime must execute your IL, so a decompiler can always run. Obfuscation can make selected details harder to read, rather than making the output unavailable — and it is worth knowing what a .NET deobfuscator can and cannot reverse when you choose which layers to apply.
• It is not encryption of your program. A determined attacker with a debugger and time can still work through obfuscated code; the point is to make that far more expensive than it is worth for most of them.
• It is not a licensing system, and no client-side check is unbreakable. Pro can add a tamper-detection self-check over virtualized methods — patching the compiled output makes those methods break rather than run altered logic — which raises the bar against casual patching. But any check that runs on the user's machine can ultimately be defeated; server-side validation is what changes the outcome, and secrets do not belong in a client binary at all — see what obfuscation actually protects against.

Compatibility checks: reflection, serialization and application behavior

Renaming can affect anything that looks up a member by its original string name. Type.GetMethod("Foo"), serializers that key on property names, DI or config that binds by convention — those names change when obfuscated. Keep [DataContract] / [JsonPropertyName] attributes explicit, and run representative application, integration and serialization tests before release. The specifics are in what breaks, and why.

Choosing a .NET obfuscator

There is no single best .NET obfuscator — there is the one that fits your constraint. The best .NET obfuscator guide ranks the options by situation; the short version: If your code cannot leave your network, a local tool is the answer (Obfuscar for renaming, ConfuserEx for depth). If you want a commercial vendor with support and stronger layers, Dotfuscator, .NET Reactor and Eazfuscator.NET go further than we do. If you want a free renaming pass with no install — the level most projects actually need — that is exactly what this tool is for, with Pro layers available when you outgrow it. The comparison pages put each option next to us honestly, including where they win.

Free vs Pro

The free tier renames symbols and offers the legacy Block ILDasm attribute online, no account required. Pro adds string encryption, control-flow obfuscation, reference proxying and method virtualization, plus 100 MB files, batch mode and the CI/CD API. Most people start free to confirm their assembly survives renaming — which flushes out reflection and serialization issues cheaply — and move up only if they decide they need the deeper layers.

Frequently asked

What is a .NET obfuscator?

A tool that rewrites a compiled .NET assembly so it is hard to read after decompilation — renaming symbols and, optionally, encrypting strings and obfuscating control flow — without changing what the program does.

Is there a free .NET obfuscator?

Yes — this one. It renames symbols online with no account or install. Deeper protection layers are on Pro.

Does obfuscation stop someone decompiling my DLL?

No tool can — the runtime needs the IL. Selected names change and additional layers can add analysis effort; the decompiled output is still available and some logic remains understandable.

How do I obfuscate a .NET DLL or EXE?

Build in Release, upload the managed assembly, then test the returned copy in your deployment folder. The service returns the result without retaining an upload archive.

What is the best .NET obfuscator?

Compare your threat model, build workflow, local-processing needs and tested compatibility. Use a before-and-after assembly and an unchanged consumer to check claims; the selection guide explains the trade-offs.

By language and output type: C# obfuscator · EXE obfuscator · DLL obfuscator. It works for anything that compiles to a managed assembly — VB.NET and F# obfuscate the same way. More background in the guides.