Decompilers on Decompiler Explorer: Full List and How Outputs Compare

Updated

Decompiler Explorer (dogbolt.org) runs the same binary through 13 decompilers and shows their C-like output side by side: angr, BinaryNinja, Boomerang, dewolf, Ghidra, Hex-Rays, Kuna, RecStudio, Reko, Relyze, RetDec, rev.ng, and Snowman. That side-by-side layout is the whole point of the site — it lets you judge readability and correctness on your own code rather than trusting a single tool's output. The comparison below covers what each decompiler is generally known for, followed by how to read the differences in practice.

The full decompiler list

Decompiler Typical character of output
angr Research-oriented; useful when you want symbolic-execution-adjacent analysis alongside decompilation
BinaryNinja Clean, structured output; strong on type recovery and interactive workflows
Boomerang Older open-source decompiler; output can be rougher on modern binaries
dewolf Academic decompiler; less commonly used, output varies by target
Ghidra Free and widely used; solid output, occasionally verbose variable naming
Hex-Rays The IDA Pro decompiler; often the readability benchmark others are judged against
Kuna Research decompiler; not aimed at production reverse engineering
RecStudio Interactive decompiler with its own GUI lineage
Reko Open-source; supports many architectures, output quality varies
Relyze Commercial tool with decompilation as one feature
RetDec Open-source, retargetable; good coverage, output can be verbose
rev.ng LLVM-based; often produces clean, compiler-like C
Snowman Lightweight standalone decompiler; readable on simple functions

Treat this as orientation, not a ranking. Output quality depends heavily on the target architecture, compiler, and optimization level — a decompiler that looks clean on one sample can look messy on another.

How the comparison actually works

You give Decompiler Explorer one binary, and it feeds that same file to every decompiler in the list, then presents the results together. Because the input is identical, any difference you see is attributable to the decompiler, not to a different build or a different disassembly.

Two practical consequences:

  • You compare apples to apples. If Ghidra names a variable local_18 and rev.ng names it var_20, that difference comes from the tools, not from the binary.
  • You can spot where tools disagree. When one decompiler reconstructs a loop or a struct access and another flattens it into gotos, that disagreement is a signal worth investigating manually.

Reading the differences: what to look for

When you open a sample and scan across the columns, focus on these dimensions rather than overall "prettiness":

  1. Control flow reconstruction. Does the tool recover for/while loops and if/else branches, or does it emit goto chains? Cleaner control flow usually means less manual cleanup.
  2. Variable and type recovery. Are locals given meaningful types (int, pointers, structs) or left as raw stack offsets? Better type recovery saves you work.
  3. Function signatures. Do arguments and return types look plausible, or are they guessed wrong?
  4. Faithfulness to the original logic. A readable decompilation that drops a bounds check is worse than an ugly one that keeps it. Cross-check against the disassembly when something looks too clean.

A useful habit: pick the decompiler whose output is easiest to verify, not necessarily the one that looks nicest. Readability helps you find the logic; correctness is what you actually need.

Using the samples to calibrate

Decompiler Explorer ships with built-in samples you can load without uploading anything, including:

  • A CTF Challenge on x86 Linux
  • Hello World on Arm Linux
  • Megatest Decompiler Test Binary: arm64 FreeBSD
  • Megatest Decompiler Test Binary: arm64 macOS
  • Megatest Decompiler Test Binary: x86 Windows
  • Ping6 on x86_64 Linux
  • VTables on x86 Windows
  • Yet Another x86 Linux CTF Challenge

These are a good way to learn each decompiler's personality before you commit to one for real work. The "Megatest" binaries in particular are designed to stress decompiler features, so differences between tools show up clearly there. The CTF samples are useful for seeing how each tool handles obfuscation or unusual control flow.

Choosing a decompiler for your workflow

There is no single winner, and the right pick depends on what you are doing:

  • If you want a free, general-purpose default: Ghidra or RetDec. Both are open source and handle a wide range of targets.
  • If readability on typical C/C++ binaries matters most: Hex-Rays (with IDA Pro) and BinaryNinja are the common choices, with rev.ng often competitive on LLVM-friendly targets.
  • If you are doing research or need to script analysis: angr and the LLVM-based rev.ng are worth a look.
  • If you just need a quick second opinion: Snowman or Reko are lightweight and easy to run.

The honest answer is that most reverse engineers keep two or three decompilers around and switch when one produces confusing output. Decompiler Explorer is built for exactly that habit — it removes the setup cost of installing each tool just to see how it handles a given binary.

Practical constraints to keep in mind

  • Upload size limit: files must be under 2MB. Larger binaries need to be trimmed or analyzed locally.
  • Uploaded binaries are retained. The site states this explicitly, so do not upload anything sensitive or proprietary.
  • It is open source. You can fork it on GitHub if you want to run it yourself or extend it.

For learning how the tools differ, the built-in samples avoid the upload question entirely and are the fastest way to get a feel for the comparison.