DLL obfuscator

Obfuscate a .NET library and keep it callable — the public API is preserved, everything private is scrambled. Free, in the browser.

Obfuscate a DLL Free vs Pro

A library's public API is its contract — so it is kept intact

If you ship a .dll that other code calls, renaming a public type or method would break every caller. So for a library the obfuscator renames private and internal members — the implementation detail an attacker actually wants — while leaving the public surface exactly as it is. Your NuGet package or SDK still binds; its internals no longer read like source.

This includes nested public types, which are easy to get wrong: a public Container.Options stays bindable. (Renaming nested public types by mistake was a real bug we fixed — see the changelog.)

When you actually want more

If the DLL is a private implementation library that nothing outside your solution references by name, you lose nothing by scrambling more of it — but the safe default for a distributed library is to preserve the public API. The tool decides "app vs library" by the presence of an entry point, not the file name.

How to obfuscate a .NET DLL

  1. Build the library in Release.
  2. Upload YourLib.dll from bin/Release/….
  3. Download YourLib.obfuscated.dll — public API unchanged, internals renamed.
  4. Reference it from a consumer and run your tests; watch for reflection or serialization that looks up internal members by name (what breaks, and why).

What it does and does not do

Renaming removes readable structure; string literals stay visible unless you enable string encryption (Pro); it is not a licensing or anti-tamper system. The threat model is honest about the limits, and the comparisons show where paid tools go further.

Shipping an application rather than a library? The EXE obfuscator page covers renaming an app's public names and the .NET Core launcher gotcha.