.NET obfuscator
Protect a .NET assembly from casual reverse engineering — free, in the browser, in about a minute. Upload a DLL or EXE; download a copy that runs identically with its internals scrambled.
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 every symbol to meaningless characters; the deeper layers encrypt strings and rearrange control flow so even the logic is hard to follow. The program still runs exactly the same — obfuscation changes how the code reads, not what it does.
How to obfuscate a .NET assembly
- Build your project in Release so you protect what you actually ship.
- Find the output —
bin/Release/net8.0/YourApp.dll(or.exe). - Upload it on the home page. Nothing is written to disk; the file is processed in memory and streamed straight back.
- 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.
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).
ValidateLicenseKeybecomes@a. Private and internal members are always renamed; for an application the public surface is renamed too, while a library keeps its public API so callers still bind. This is the single most valuable layer — it removes the readable map of your code. - Block ILDasm (free). Marks the assembly so Microsoft's IL disassembler refuses it. A trivial speed bump on its own, but free and harmless.
- 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 tangled shape — flattened branches and opaque predicates — so the decompiled output no longer reads as clean structured code even after names are gone.
- Reference proxying (Pro). Routes calls to framework and library methods through generated proxies, hiding the direct call graph that reveals what your code is doing.
- Method virtualization (Pro). The strongest layer: eligible 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 makes what comes out unreadable, not unavailable.
- 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 or anti-tamper system. A check that runs on the user's machine can be defeated. Obfuscation raises the bar; server-side validation changes the outcome. Secrets do not belong in a client binary at all — see what obfuscation actually protects against.
The one thing to test: reflection and serialization
Renaming preserves behaviour with one exception: 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
the obfuscated build once 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. 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 blocks ILDasm in the browser, 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 in the browser 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. Obfuscation makes the decompiled output meaningless rather than preventing the decompile.
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.