dogbolt.org

Decompiler Explorer (dogbolt.org) is open source, and the project page links directly to its GitHub repository with an invitation to fork it. If you want to read the implementation, run your own instance, or contribute changes, GitHub is the place to start — the site itself only exposes the link, not the code.

What the site tells you

The Decompiler Explorer page ends with a short, explicit statement: the project is open source, and you can fork it on GitHub. That is the only source-code pointer the page provides. There is no separate "download" section, no tarball, and no self-hosted mirror mentioned in the page content.

How to get to the source

1. Open dogbolt.org.
2. Scroll to the bottom of the page.
3. Follow the GitHub link in the "Decompiler Explorer is open source!" line.
4. On GitHub, use Fork to create your own copy, or clone the repository if you only want to read and build locally.

Expected result: you land on the project's repository, where the full source, commit history, and issue tracker live. Because the page only says "fork it on GitHub" without naming the exact repository path, treat the link on the page as the authoritative entry point rather than guessing a URL.

What you can do once you have it

• Read the implementation to see how the front end submits a binary and how it collects output from each decompiler.
• Fork and modify — the page explicitly frames forking as the intended path, which suits experimenting with your own build.
• Track updates — GitHub is where new decompiler integrations and fixes would appear, since the site content itself is static.

Practical notes before you start

• The upload limit stated on the page is 2MB per file, which is a useful constraint to keep in mind if you are testing your own instance with the same sample set.
• The page lists a set of built-in samples (for example, a CTF challenge on x86 Linux, Hello World on Arm Linux, and several "Megatest" binaries for arm64 FreeBSD, arm64 macOS, and x86 Windows). These are handy for verifying that a local build behaves like the hosted one.
• The decompilers referenced on the page include angr, BinaryNinja, Boomerang, dewolf, Ghidra, Hex-Rays, Kuna, RecStudio, Reko, Relyze, RetDec, rev.ng, and Snowman. If you plan to contribute, expect the code to deal with wiring several independent tools together rather than a single decompiler.

If the GitHub link is not enough

The page does not document build steps, dependencies, or a contribution guide. Those details, if they exist, would live in the repository itself — check its README and issue tracker first. If you cannot find the link on the page, reload dogbolt.org and look at the footer text, since that is the only place the source reference appears.

Decompiler Explorer is a browser-based tool that runs a binary through many popular decompilers at once and shows their C-like output side by side. To use it, either upload a file under 2MB or pick one of the provided samples; no account or installation is needed. Uploaded binaries are retained, so don't submit anything you can't share.

What you get

The page is built around a single comparison view. After you supply a binary, it lists the available decompilers — angr, BinaryNinja, Boomerang, dewolf, Ghidra, Hex-Rays, Kuna, RecStudio, Reko, Relyze, RetDec, rev.ng, and Snowman — and shows each one's equivalent C-like output for the same input. That makes it useful for seeing where decompilers agree, where they diverge, and which one handles a given construct more readably.

Option 1: Upload your own file

1. Find the Upload File control on the page.
2. Select a binary from your machine. It must be less than 2MB.
3. Submit it and wait for the decompiler outputs to render.

Expected result: the comparison view populates with output from the available decompilers. If nothing appears, the most likely cause is that the file exceeded the 2MB limit or wasn't a format the tooling could parse.

Note the retention behavior: uploaded binaries are kept. Treat every upload as public and strip anything sensitive before submitting.

Option 2: Use a provided sample

If you just want to see how the tool works, skip the upload. Open the Select a Sample... dropdown and choose one of the bundled binaries:

• 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

The samples cover multiple architectures and platforms, so they're a quick way to compare how each decompiler handles different instruction sets and binary formats. The "Megatest" binaries in particular are designed to stress-test decompiler output.

Choosing between upload and sample

Practical tips

• Start with a sample to learn the layout before uploading your own file.
• Compare outputs across decompilers rather than trusting a single one; disagreement between them often points to the tricky parts of the binary.
• Since uploads are retained, work on copies and avoid proprietary or personal binaries.

The project is open source and can be forked on GitHub if you want to run or modify it yourself.

Yes. Decompiler Explorer (dogbolt.org) states on its upload page that uploaded binaries are retained. The page also sets a 2MB size limit per file. If you are thinking about uploading a proprietary or sensitive binary, treat it as data that stays on the service rather than something that is deleted after analysis.

What the site says about uploads

The relevant statements come directly from the upload interface:

• Retention: "Uploaded binaries are retained." This is a plain notice, not a promise of automatic deletion.
• Size limit: "Your file must be less than 2MB in size." Files at or above that limit are not accepted.
• Open source: The project describes itself as open source and points to GitHub for the code. You can inspect the source to understand how the service is built, but the retention notice is about the running service, not just the code.

What this means for safety

The tool is designed for inspecting and comparing decompiler output, not for confidential analysis. A few practical implications:

• Do not upload anything you would not want stored on a third-party server. That includes proprietary firmware, internal tools, licensed software, or binaries containing credentials, keys, or customer data.
• Assume the file can persist. Because the page says binaries are retained, plan as if the upload is durable. There is no stated deletion control on the page.
• The 2MB limit is a hard constraint. If your target is larger, you cannot use the hosted upload as-is.

When it is reasonable to use

Decompiler Explorer is a good fit when the binary is already public or non-sensitive:

• CTF challenge binaries and other publicly distributed samples.
• Open-source or otherwise freely redistributable programs.
• Small test binaries you created yourself for comparing decompilers.
• The built-in samples the site provides, such as the x86 Linux CTF challenge, Arm Linux Hello World, and the arm64/x86 "Megatest" binaries.

For anything private, the safer path is to run decompilers locally or in your own controlled environment instead of uploading to a shared service.

Practical checklist before uploading

1. Confirm the file is under 2MB.
2. Confirm you are allowed to share the binary with a third party.
3. Confirm it contains no secrets, credentials, or personal data.
4. If any answer is uncertain, do not upload — use a local decompiler setup instead.

The short version: the site is transparent that uploads are retained, so its safety depends entirely on what you choose to upload. Public samples are fine; sensitive binaries are not.

Decompiler Explorer is a free online tool that takes a compiled binary and shows you the C-like output produced by many different decompilers side by side. If you want to compare how Ghidra, Hex-Rays, BinaryNinja, RetDec, and others interpret the same machine code, this is the fastest way to do it without installing each tool locally. It works on uploaded binaries under 2MB, or on a set of built-in sample files.

What it does

The core idea is simple: decompilers disagree. Given the same executable, each one reconstructs different variable names, control flow, and type information. Decompiler Explorer runs your binary through a whole panel of them and lays the results out for direct comparison.

The decompilers listed on the site are:

• angr
• BinaryNinja
• Boomerang
• dewolf
• Ghidra
• Hex-Rays
• Kuna
• RecStudio
• Reko
• Relyze
• RetDec
• rev.ng
• Snowman

Each one produces its own C-like rendering of the disassembled logic, so you can see where they agree and where one recovers structure the others miss.

How to use it

1. Upload a file — the binary must be smaller than 2MB. Uploaded binaries are retained, so don't submit anything sensitive.
2. Or pick a sample — the site provides preloaded binaries if you just want to explore. These include:
   • 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
3. Compare the output — the decompiled results appear for each supported decompiler, letting you judge which one handles your target best.

When it's useful

• Choosing a decompiler: If you're deciding which tool to buy or learn, run a representative binary through all of them first.
• CTF and reverse engineering: The sample set is CTF-oriented, and the comparison view helps when one decompiler produces confusing output and another clarifies it.
• Cross-checking results: When a single decompiler gives you something that looks wrong, seeing a second or third opinion can confirm or refute it.
• Architecture coverage: The samples span x86, x86_64, arm64, Linux, Windows, macOS, and FreeBSD, so you can test how tools handle different platforms.

Limitations to keep in mind

• 2MB upload cap — larger binaries won't work.
• Retention — uploaded binaries are retained, so treat it as a public-ish service and avoid proprietary or sensitive files.
• No pricing information is provided on the site, so the tool itself is presented as an interactive online service without stated cost details.

Open source

Decompiler Explorer is open source and can be forked on GitHub, so you can inspect how it works or run your own instance if you need to handle binaries you can't upload publicly.

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

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.