Frequently asked questions

Managed .NET assemblies — a .dll or .exe produced by the C#, VB.NET or F# compiler. This includes .NET Framework, .NET Core, .NET 5 and later.

Native binaries will not work, because there is no managed metadata to rewrite. That includes C and C++ executables and .NET apps published with NativeAOT.

No. Obfuscation operates on the compiled assembly's metadata, so only the built .dll or .exe is needed. Your source never leaves your machine.

Not for the free tier. You can obfuscate a file up to 1 MB without signing up. An account is only required for Pro, which raises the limit to 100 MB, allows batches of up to 20 files, and unlocks the API.

In most cases yes. Only metadata is rewritten — the IL is untouched, so the logic executes exactly as before.

The exception is anything that looks up a type or member by name at runtime: reflection, serialization, XAML bindings and convention-based dependency injection. Several protections are built in (see below), but you should still smoke-test the obfuscated build before shipping it.

Yes, always. Obfuscation is one-way — the original names cannot be recovered from the protected copy. Archive the unobfuscated build alongside its symbols so you can still debug production issues.

It renames the identifiers in your assembly's metadata. A method called ValidateLicense becomes a short, meaningless name, as do fields, properties, parameters and non-public types. A decompiler can still reconstruct the logic, but without the names that made it readable.

Read how .NET decompilers read your code for the mechanics.

Quite a lot, and for good reason. The following are never renamed, because renaming them would break working code:

• Types marked [Serializable], so serialization keeps working.
• Compiler-generated types, and anything marked [GeneratedCode].
• virtual and abstract members, so overrides and interface implementations still bind.
• Constructors, and the Main entry point.
• Enums, and generic types.
• Public types. Their non-public members can still be renamed.

These exclusions are why most applications obfuscate cleanly on the first attempt.

No. This tool does symbol renaming only. There is no string encryption, control-flow obfuscation, anti-debugging or anti-tamper.

String literals therefore survive untouched, which matters: searching for user-visible text remains an effective way to locate code. If you need deeper protection, the comparisons covers tools that provide it.

A library's public surface is its contract with callers — renaming it would break everything compiled against it. An application is normally the end of the dependency chain, so its public members can usually be renamed safely.

The full explanation covers when to enable it and when not to.

The original names cannot be recovered — they are not stored anywhere, in the file or by us. Someone can still rename symbols back to something meaningful by reading the code and inferring intent, but that is manual reverse engineering, not an undo.

This applies to you as well: there is no way to deobfuscate your own file. Keep the original.

Rewriting an assembly invalidates any existing signature. If your assembly is strong-named or Authenticode-signed, obfuscate first and sign afterwards, as the last step before publishing.

The output does not carry debug symbols, and your existing .pdb will no longer match the obfuscated assembly. That is usually what you want when shipping. Keep the original build and its symbols privately so you can still interpret stack traces.

Free handles one file at a time, up to 1 MB, with no account required. Pro is $29/month and raises this to 100 MB per file, batches of up to 20 files, and adds API access for build pipelines.

The obfuscation itself is identical on both tiers.

Obfuscation is CPU-bound, so only a limited number of jobs run at once. When every slot is busy, further requests wait — and Pro requests are handed the next free slot ahead of Free ones.

It does not make your obfuscation run faster. An individual job takes the same time on both tiers. What it changes is what happens under load: Pro requests wait for a slot rather than being turned away, while Free requests give up after a short wait and ask you to retry.

On an idle server there is no queue and no difference between the tiers.

From your account page, choose Manage billing to open the Stripe billing portal, where you can cancel yourself. No email required.

Pro access continues until the end of the period you have already paid for, then the account reverts to Free. Your account and login remain.

Your account is marked past due and Pro features keep working while Stripe retries the payment. Your account page will show a warning with a link to update your payment method. If the retries are exhausted the subscription is cancelled and the account returns to Free.

Get in touch and we will sort it out. Since you can cancel at any time from the billing portal, and cancelling stops any future charge, most billing questions are resolved that way.

No. Payments are handled entirely by Stripe. Card details never reach our servers — we only store a Stripe customer and subscription identifier so we know which plan you are on.

A key is generated automatically when a Pro subscription becomes active, and appears on your account page. You can also generate one there manually if you need it immediately.

The old key stops working immediately — there is no grace period. Anything using it, particularly CI pipelines, will start returning 401 until you update the stored secret. Rotate and update the secret in the same change.

No — the API takes one assembly per request. To protect several assemblies, call it once per file; they are independent, so the calls can run in parallel. Batch upload of up to 20 files at once is available through the web interface.

It is a single multipart POST, so any CI system can call it with curl or its native HTTP client. Obfuscating .NET builds in CI/CD has complete working examples for GitHub Actions and Azure Pipelines, including how to fail the build properly when the call errors.

The file could not be read as a managed .NET assembly. The usual causes are a native binary or NativeAOT publish, a corrupted upload, or an assembly that has already been through another obfuscator or packer.

Confirm the file opens in a tool such as ILSpy. If it does not, it is not a managed assembly.

Almost always something resolving a member by name at runtime. Check, in order: reflection calls such as GetMethod or GetProperty; serialization round-trips; dependency-injection registration that scans by type name; and Entity Framework convention-based mapping.

Obfuscation and reflection lists each failure mode with its fix.

Classic symptom of XAML bindings failing to resolve. WPF does not throw when a binding cannot be resolved — it writes a trace warning and renders nothing.

Anything referenced from XAML needs to keep its name. For desktop applications, test every view after obfuscating, and try leaving public renaming off if bindings break.

The free tier accepts files up to 1 MB. Pro raises this to 100 MB per file, which covers all but the most unusual assemblies. If your assembly exceeds 100 MB, get in touch.

Expected in a few cases. If the assembly is mostly public API surface on a library, or mostly generic types, [Serializable] types or interfaces, much of it is deliberately excluded from renaming to avoid breaking your code — see what is left alone above.

For an EXE, check whether enabling obfuscate public names gives you more coverage.

No. Uploads are processed in memory and streamed straight back in the response. Nothing is written to disk on the server and nothing is retained once the response completes.

For most commercial software, yes — the file is processed in memory, never stored, and transferred over HTTPS.

That said, be honest about your own constraints: the assembly does leave your network. If you are working under classification, a regulatory regime, or a contract that forbids sending build artifacts to third parties, use a local tool instead. The comparisons covers options that run entirely on your machine.

For registered users: your email address, a password hash, and your subscription status. Payment details are held by Stripe, not by us. See the privacy page for detail.