EXE Decompiler Online

What is an EXE File?

EXE (Executable) is the standard file format for programs on Windows. There are two main categories of EXE files: native executables compiled from languages like C and C++, and managed executables built with .NET languages like C#, VB.NET, and F#.

This tool focuses on .NET executables. Unlike native code that compiles to machine instructions, .NET code compiles to CIL (Common Intermediate Language) — a platform-independent bytecode that runs on the .NET runtime. Because CIL retains rich type information, method signatures, and metadata, it can be decompiled back to high-quality source code.

How .NET EXE Decompilation Works

When a .NET application is built, the compiler (csc for C#, vbc for VB.NET) produces CIL bytecode rather than native machine code. This bytecode is stored in a PE (Portable Executable) file along with extensive metadata including type definitions, method signatures, and assembly references.

The decompiler reads this CIL bytecode and metadata, then reconstructs high-level source code. It can recognize and reconstruct complex language features:

• LINQ queries and lambda expressions
• Async/await patterns
• Pattern matching and switch expressions
• Properties, events, and indexers
• Generics and nullable types
• Using statements and exception handling

.NET EXE vs Native EXE

It is important to understand the distinction between .NET and native executables:

• .NET EXE — contains CIL bytecode with rich metadata. Can be decompiled to readable C# or VB.NET. This tool handles these files.
• Native EXE — contains machine code compiled from C, C++, Delphi, etc. Can only be disassembled to assembly language, not high-level source code. Tools like IDA Pro or Ghidra are used for this.

Uploading a native EXE no longer produces an empty result. The .NET decompiler is skipped — the absence of a CLR directory in the PE header says there is no CIL to read — and the file is inspected structurally instead. That is metadata and resource extraction, not source recovery, and the result says so.

What You Get From a Native EXE

Every Windows executable is read for the information its own structure carries, whether or not it is a .NET assembly:

• info/pe.json — architecture (x86, x86-64, ARM64), subsystem, linker version, entry point, image base, the full section table and every data directory
• info/imports.txt — every DLL the program links against and every function it imports from each, including delay-loaded imports
• info/exports.txt — exported functions with their ordinals, and forwarders where present
• info/version.txt — company, product, file version and original filename from the version resource
• resources/ — icons rebuilt into openable .ico files, bitmaps, the application manifest as XML, decoded string tables, and every other resource blob with its id and language

An Authenticode certificate table is reported as present or absent. That is not a signature check: nothing is hashed and no certificate chain is built.

None of this is decompiled source. A binary compiled from C, C++, Delphi or Rust keeps no type or method metadata, which is exactly what makes C# recovery possible for .NET; reading its machine code is a job for a disassembler such as Ghidra or IDA.

Packed Executables

A UPX-packed program has its real sections compressed into one blob, so a packed upload appears to import almost nothing. When the file is confirmed packed — by running UPX itself, not by trusting UPX0 section names, which anything can write — it is expanded to a separate copy and that copy is classified again. If what is underneath is a .NET assembly, a PyInstaller launcher or a Godot game, it reaches the decompiler for that format; otherwise it gets its own structural report. The uploaded file is never modified and neither the packed nor the unpacked program is ever run. Modified UPX builds and commercial protectors are out of scope.

Is the EXE a Packaged Python App?

PyInstaller and py2exe applications are native launchers around Python bytecode, not .NET assemblies. They are detected before the C# decompiler and routed to the PyInstaller and py2exe decompiler, which extracts their .pyc modules and recovers Python source where the bytecode version is supported.

Obfuscated .NET Executables

Many commercial .NET applications use obfuscators (like Dotfuscator, ConfuserEx, or SmartAssembly) to make decompilation harder. Common obfuscation techniques include renaming identifiers to meaningless characters, encrypting string literals, injecting anti-tamper checks, and adding control flow obfuscation.

Even with obfuscation, the underlying CIL bytecode must remain valid for the .NET runtime to execute it. This means the code structure is always recoverable — just harder to read. The decompiler will produce valid but obfuscated-looking source code.

Frequently Asked Questions