JADX vs JEB vs Apktool: Which Android Decompiler for Which Job

Short answer, as of 2026-10-14: these three tools are not really competitors. JADX turns DEX bytecode into readable Java and is what you open to understand logic. Apktool decodes resources and the manifest into editable XML and turns DEX into smali, the assembly language of the Android runtime. JEB is a commercial analysis platform from PNF Software with its own Android decompiler, deobfuscation modules and native-code decompilers. Most people use JADX and Apktool together and add JEB only when the free tools stop being enough.

This page is for Android developers and security engineers deciding what to install. It compares outputs on the same open-source APK, with timings, then covers pricing, licences and how REA (the open-source project by morluto) drives each tool.

What I ran and what I did not. I ran JADX 1.5.6 and Apktool 3.0.3 on macOS (Apple M5 Pro, 24 GB, Temurin JDK 17.0.18), and I ran REA 6.4.0’s JADX and Apktool commands. I did not run JEB: it is commercial, and the free Community Edition does not include the Dalvik decompiler. Everything about JEB below is from PNF Software’s own pages, checked on 2026-10-14.

Sample: the F-Droid client, version 2.0.1 (versionCode 2000051), downloaded from https://f-droid.org/F-Droid.apk (12,537,183 bytes). It is GPL-3.0 and its source is on GitLab, so any decompiled output can be checked against the original. Use the same steps on your own APKs. Analyze only apps you own, open-source apps, or apps you are authorized to examine, and read REA’s DISCLAIMER.md.

One-line verdict per tool

The same APK through JADX and Apktool

Commands and timings

jadx -d out/jadx F-Droid.apk
java -jar apktool_3.0.3.jar d -o out/apktool F-Droid.apk
java -jar apktool_3.0.3.jar d --no-src -o out/apktool-nosrc F-Droid.apk

I wrapped each in /usr/bin/time -l. These are single runs on one machine, so treat them as orders of magnitude:

JADX did much more work: it decompiles every method to Java, here on 7 threads (the default it picked on this machine). It ended with ERROR - finished with errors, count: 147. That does not mean the run failed. JADX writes all the code it can, and marks methods it could not decompile cleanly with comments in the output. Inside the app’s own org/fdroid package, 293 of 990 Java files carry at least one JADX WARN, JADX ERROR or “Code decompiled incorrectly” comment. The most common one is 'super' call moved to the top of the method, which is cosmetic. Expect this on any large Kotlin app, and read flagged methods with care.

Same method, two views

The class org.fdroid.CompatibilityCheckerUtils is small and easy to compare. JADX’s Java for one method:

public final int minInstallableTargetSdk(int sdkInt) {
    switch (sdkInt) {
        case 34:
            return 23;
        case 35:
        case 36:
        case 37:
            return 24;
        default:
            return 1;
    }
}

Apktool’s smali for the same method:

.method public final minInstallableTargetSdk(I)I
    .locals 0

    .line 0
    const/16 p0, 0x18

    packed-switch p1, :pswitch_data_0

    const/4 p0, 0x1

    :pswitch_0
    return p0

    :pswitch_1
    const/16 p0, 0x17

    return p0

    :pswitch_data_0
    .packed-switch 0x22
        :pswitch_1
        :pswitch_0
        :pswitch_0
        :pswitch_0
    .end packed-switch
.end method

And the original Kotlin from the 2.0.1 tag (libs/index/src/androidMain/kotlin/org/fdroid/CompatibilityChecker.kt):

public fun minInstallableTargetSdk(sdkInt: Int = SDK_INT): Int {
    return when (sdkInt) {
      34 -> 23 // Android 6.0, M
      35 -> 24 // Android 7.0, N
      36 -> 24 // Android 7.0, N (didn't change)
      37 -> 24 // Android 7.0, N (didn't change in SDK 37 beta 4)
      else -> 1 // Android 1.0, BASE
    }
}

The JADX version is the one you can read in five seconds, and it matches the source exactly. The smali is the truth at the bytecode level: one packed-switch table starting at 0x22 (34), with the compiler reusing register p0. When JADX output looks wrong or carries a warning, smali is what you check it against. JADX also generated the Kotlin default-argument bridge minInstallableTargetSdk$default, which in the source is just = SDK_INT, and kept the @Metadata annotation that Kotlin emits.

Resources

Both tools decode AndroidManifest.xml and the resource table to XML. Apktool writes a project you can work in: res/ with 539 strings in res/values/strings.xml, an apktool.yml with minSdkVersion: 24, targetSdkVersion: 37 and versionName: 2.0.1, and smali, smali_classes2 and smali_classes3 for the three DEX files. JADX puts its decoded resources under resources/, next to sources/.

Apktool can also rebuild a decoded folder (apktool b). That is for your own app’s resources and is outside the scope of this page.

JEB: what you get for the money

From PNF Software’s JEB page, pricing page and changelog, checked 2026-10-14:

• Current version: JEB 5.48, dated 2026-10-07.
• Editions: JEB Community Edition (free), JEB Android and JEB Pro. In the features matrix, the Dalvik decompiler is ticked for JEB Android and JEB Pro, not for CE. CE does include the x86 and x86-64 decompilers and a Dalvik disassembler.
• Pro-only rows: the deobfuscation module for “virtualized” code, deobfuscators that use native code emulation (JNI), a generic APK unpacker plugin, “Automation / headless launcher” and “Work offline”.
• Prices listed: JEB Android $1,200 per user per year, or $140 per user per month; JEB Pro $2,000 per user per year; JEB Pro Floating $4,000 per seat per year. Priority support for Pro is an extra 30%.
• MCP: the changelog lists an MCP server in recent versions. 5.41 added a command-line option to “start JEB in headless mode with the MCP server on (on the command-line: jeb -c –mcp)” and switched it to streamable HTTP. 5.47 and 5.48 added more MCP tools.

The matrix and changelog do not say which editions include the MCP server. Since headless mode is a Pro-only row, check with PNF Software before you plan a headless agent setup on another edition.

How REA uses each tool

REA 6.4.0 installs none of them. You point it at tools you installed.

JADX through jadx-headless-mcp. REA pins version 0.7.1 of that JAR; the SHA-256 of the file I downloaded, 6e5eacf5...ff75, matched the one REA reports. Set REA_JADX_MCP_JAR to the JAR and have a full JDK 17+ on the path. The commands are inspect-android-package, search-android-classes, inspect-android-class, inspect-android-method and trace-android-references. On the F-Droid APK:

rea inspect-android-package /abs/F-Droid.apk --json
rea inspect-android-method /abs/F-Droid.apk org.fdroid.CompatibilityCheckerUtils minInstallableTargetSdk --overload-index 1 --json

The package call took about 5 seconds and reported package org.fdroid.fdroid, version 2.0.1, class_count 11,959, resource_count 973, and engine jadx-headless-mcp 0.7.1 with a 6,144 MiB heap limit. The method call returned the same Java as the JADX CLI, with representation: "java", fell_back: false and overload_count: 2 (the second overload is the $default bridge, so --overload-index is required). Full setup is in JADX MCP server setup.

Apktool through REA_APKTOOL_COMMAND, an absolute path to a launcher. I used a two-line shell script that runs java -jar apktool_3.0.3.jar "$@". rea inspect-apktool-client reported apktool_version: "3.0.3", and rea decode-android-resources /abs/F-Droid.apk --json took about 3 seconds. It runs apktool d --no-src in a temporary workspace and returned the manifest, the version and SDK facts, 539 default strings and 45 string locales. Its limitation line says smali is skipped because “Java-source recovery belongs to the JADX family”.

JEB through MCP. REA 6.4.0 connects to a JEB client you started yourself at REA_JEB_MCP_URL, default http://127.0.0.1:8425/mcp, and accepts only loopback hosts. The tools are inspect_jeb_client, open_jeb_project, list_jeb_units and decompile_jeb_item. REA never installs or launches JEB. I did not test this path.

For the wider workflow with ADB and Flutter apps, see Android APK analysis with REA.

Licences and platforms

JADX’s release also offers a Windows GUI bundle with a JRE. JADX accepts .apk, .dex, .jar, .class, .smali, .aar, .aab, .xapk and .apkm, among others, according to its --help.

Common combinations

1. Logic first: open the APK in jadx-gui or run jadx, search for the class, read the Java.
2. Resources and exact bytecode: run apktool d alongside it, and compare smali when JADX flags a method.
3. Before either: drop the APK into the site’s APK analyzer to check the manifest, permissions, native libraries and signing in the browser, without uploading. It does not decompile code.
4. When to consider JEB: heavy obfuscation or virtualization, native libraries you also need decompiled in the same project, or a team that needs vendor support. Try it on your own target before buying.

FAQ

Is JADX better than dex2jar plus JD-GUI? JADX decompiles DEX directly to Java, without converting to JAR first. I did not test dex2jar for this article.

Why does JADX output contain “Code decompiled incorrectly”? Some methods cannot be turned into valid Java. JADX keeps going and marks them. Check those methods in smali, or with --show-bad-code.

Does Apktool decompile to Java? No. It produces smali, plus decoded resources.

Is JEB Community Edition enough for APKs? According to the features matrix, CE has a Dalvik disassembler but not the Dalvik decompiler, which is in JEB Android and JEB Pro.

Next steps

• Set up JADX for an AI agent: JADX MCP server with Claude Code and REA
• The full static Android workflow: Android APK analysis with REA
• Unpack AABs and assets: AAB to APK and APK unpack
• Check an APK in the browser: APK and AAB analyzer