jadx: Android Decompiler for Dex to Java
/jadx
jadx is the go-to command-line and GUI decompiler for turning Android APK and DEX files back into readable Java source. Reach for it when you need to read an app's logic fast — audit a permission, trace a callback, check what a library actually does — not when you need a perfect, compilable rebuild of the original project, because jadx openly admits it can't restore 100% of the code.
What is jadx?
jadx is a Dex to Java decompiler with both a command-line tool and a GUI, built to turn compiled Android bytecode back into source you can actually read. Point it at an APK, DEX, AAR, AAB, JAR, class, smali, or zip file and jadx rebuilds the Java classes, unpacks AndroidManifest.xml and the resources.arsc table, and runs a built-in deobfuscator on renamed classes and methods.
Key features of jadx
- ✓Command-line and GUI modes built on the same decompiler core, so batch jobs and interactive browsing hit identical output.
- ✓Reads APK, DEX, AAR, AAB, JAR, class, smali, and zip inputs directly — no separate unzip-and-convert step.
- ✓GUI adds syntax-highlighted source browsing, jump-to-declaration, find-usage, and full-text search across a whole decompiled project.
- ✓Built-in deobfuscator renames obfuscated classes, fields, and methods using configurable name-length and whitelist rules.
- ✓Smali debugger in jadx-gui lets you set breakpoints and step through bytecode-level execution, per the project's wiki.
- ✓Decompilation mode is configurable — auto, restructure, simple, or fallback — trading readability for accuracy on stubborn code.
- ✓Plugin system with a `plugins` command to install, list, update, and disable jadx-plugins-list marketplace extensions.
- ✓Can export a decompiled APK straight to a Gradle project (Android app, Android library, or plain Java) with `--export-gradle`.
Installing jadx
On Arch Linux: `sudo pacman -S jadx`. On macOS: `brew install jadx`. Via Flathub: `flatpak install flathub com.github.skylot.jadx`. Otherwise, download the latest release zip from the GitHub releases page (or the unstable nightly build), unpack it, and run the scripts in the `bin` directory — `jadx` for the command-line tool, `jadx-gui` for the UI. On Windows, double-click the `.bat` files. Either way you need Java 11 or later, 64-bit, installed first. To build from source instead, clone the repo and run `./gradlew dist` with JDK 17 or higher; the built scripts land in `build/jadx/bin` and a zip in `build/jadx-<version>.zip`.
Decompiling your first APK
Basic form: `jadx -d out app.apk` — jadx writes decompiled Java sources and decoded resources into the `out` directory. Add `--no-res` to skip resource decoding, or `--single-class com.example.MainActivity` to pull just one class by name. Pass `--deobf` to turn on the built-in deobfuscator, or `--show-bad-code` to keep methods jadx couldn't cleanly restructure instead of dropping them. Running `jadx-gui app.apk` opens the same decompiler in the GUI, where you get syntax highlighting, jump-to-declaration, and full-text search over the whole output.
Strengths
- ✓Single tool covers CLI batch decompiling and interactive GUI browsing — no separate installs for scripting versus exploring.
- ✓Wide input support: APK, DEX, AAR, AAB, JAR, class, smali, and zip all load without a manual conversion step.
- ✓Runs from a single unpacked zip — no installer required.
- ✓Deobfuscation and the smali debugger are built in, not bolted-on plugins you have to hunt down separately.
- ✓Plugin system extends it — dex-input, java-convert, kotlin-metadata, rename-mappings, smali-input — without forking the core.
Known decompilation limitations
- △jadx can't decompile 100% of code in most cases — the README warns errors will occur and points to a troubleshooting wiki page.
- △Heavily obfuscated or control-flow-flattened bytecode can produce incomplete or outright wrong Java, not just ugly Java.
- △The smali debugger setup lives entirely in a separate wiki page, not the main README, so first-time setup takes extra digging.
- △No built-in APK repackaging or recompilation — jadx reads bytecode, it doesn't rebuild a signed APK from your edits.
How jadx compares to other decompilers
Frequently asked questions
jadx supports APK, AAR, and AAB files directly, along with DEX, JAR, class, smali, and zip inputs — you don't need to unpack or convert them first; jadx reads the format and decompiles the Dalvik bytecode inside.
jadx can be used as a library inside your own Java project, not just as a standalone CLI or GUI tool — the project's wiki has a dedicated 'Use jadx as a library' page covering setup and the API.
Run jadx with the `--deobf` flag to turn on its built-in deobfuscator, which renames obfuscated classes, fields, and methods. You can tune `--deobf-min`/`--deobf-max` for name length, set a whitelist of packages to skip, and point `--mappings-path` at a Tiny, Tiny v2, or Enigma mapping file if you already have one.
jadx openly states it can't decompile all code in most cases, and errors will occur — the README calls this out directly and links a troubleshooting wiki page. Heavily obfuscated, control-flow-flattened, or non-standard bytecode is the usual cause; the `--show-bad-code` and fallback decompilation modes exist specifically to surface those cases instead of hiding them.
Running the pre-built jadx or jadx-gui release needs Java 11 or later, 64-bit, installed on your system. Building jadx from source is stricter: the README requires JDK 17 or higher to run `./gradlew dist`.
jadx-gui includes a smali debugger that lets you set breakpoints and step through bytecode-level execution, with setup and usage documented on a dedicated wiki page. This debugging feature is part of jadx-gui, not the plain command-line jadx tool.
The problem it solves
Android ships as compiled DEX bytecode inside an APK, and there's no first-party way to get back to something a person can read — you either trust the developer's word about what an app does, or you dig through raw Dalvik instructions by hand. jadx exists to close that gap: point it at the APK and it hands you Java source, a decoded manifest, and unpacked resources instead of bytecode.
Best use cases
- •Auditing a third-party APK for suspicious network calls or permission misuse before installing it internally.
- •Recovering readable source for an old in-house Android app whose original project was lost.
- •Debugging a crash in a release build by reading the decompiled stack trace against the original obfuscated names.
- •Stepping through Dalvik bytecode with the jadx-gui smali debugger while reverse-engineering a protocol or SDK.
Who should try it — and who should skip
Try jadx if you regularly need to read Android app internals — security researchers auditing APKs, developers recovering a lost project's source, or anyone debugging a crash against an obfuscated release build. Skip it if you need a guaranteed, compilable rebuild of the original app: jadx's own README admits it can't restore all code, and heavily obfuscated or protected APKs will come back with gaps you have to fill in by hand.
Related repositories
Still deciding about jadx?
One click hands the question to an AI along with this page — see what it says about jadx.