# Bytecode Viewer: a Java and APK reverse engineering suite that runs six decompilers side by side

> Bytecode Viewer bundles six Java decompilers, three disassemblers and two APK converters behind one drag-and-drop window. It is a desktop tool for engineers who need to read someone else's Java or Android build, and its GPL-3.0 licence and Maven-only build path shape who can use it.

**Konloch/bytecode-viewer** — A Java 8+ Jar & Android APK Reverse Engineering Suite (Decompiler, Editor, Debugger & More)

- Repository: https://github.com/Konloch/bytecode-viewer
- Website: https://bytecodeviewer.com
- Stars: 15,656 · Forks: 1,287
- Language: Java
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/konloch-bytecode-viewer

## What Bytecode Viewer is for, and who actually needs it

Bytecode Viewer (BCV) is a desktop application for reading compiled Java and Android artifacts. The README describes it as "a lightweight user-friendly Java/Android Bytecode Viewer, Decompiler & More" and lists file format support for Class, Jar, APK, DEX, XAPK, APKM, WAR, JSP, image resources and text resources. The audience is narrow and specific: someone holding a jar or an APK with no matching source, who needs to understand what it does.

That covers a few real jobs. Auditing a third-party dependency before it ships. Checking whether an obfuscated Android build contains something it should not. Recovering intent from a library whose repository disappeared. The tool is a reading instrument, not a build tool and not a scanner that produces a report you can hand to someone else.

The project is written in Java and targets Java 8 and above. It is not archived, and the last push to the default branch was on 2026-07-17. The most recent tagged release is v2.13.2, dated 2026-01-01. That is a slow but non-zero cadence, and the release titles themselves say "In-Dev", which is worth reading literally rather than as a stable channel.

## Six decompilers in one window: the mechanism behind the view panes

The design decision that defines BCV is that it does not pick a decompiler for you. It ships six: Krakatau, CFR, Procyon, FernFlower, JADX and JD-GUI. Alongside them sit three disassemblers, two of which (Krakatau and Smali/BakSmali) are also assemblers, plus Dex2Jar and Enjarify for APK and DEX conversion.

The README explains the interface: "The view panes are-used to display up to 3 decompilers side by side, you can also toggle edibility here." So the workflow is comparative. You open a class, put CFR in View 1 and Procyon in View 2, and read the two outputs against each other. Decompilation is a lossy reconstruction, and different engines fail differently on the same input. Seeing two reconstructions side by side is a practical way to spot where one of them invented a control-flow shape that is not in the bytecode.

The plugin system is the second mechanism. According to the README, when a plugin is activated it "will execute the plugin with a ClassNode ArrayList of every single class loaded in BCV", which means plugins operate through ASM on the full loaded class set. The README gives a String deobfuscator or a malicious code searcher as examples, and states the system supports Java and JavaScript scripting. That is a genuinely extensible surface rather than a fixed feature list, and it is the part of BCV that is hardest to replace with a shell script.

Export is the third. The README lists export as a runnable jar, a zip, an APK, or "Decompile All As Zip". That last one is the escape hatch when you want the decompiled output outside the GUI.

## Installing Bytecode Viewer and decompiling your first jar

There is no package manager route documented. The README says to download the latest version from the GitHub releases page and run the jar, and notes you may need to launch it from the command line. Replace the X in the filename with the current minor version.

```bash
java -jar Bytecode-Viewer-2.10.x.jar
```

If you get a java.lang.OutOfMemoryError, the README's own remedy is to raise the heap ceiling. It gives this exact form:

```bash
java -Xmx3G -jar BCV.jar
```

The GUI path is drag and drop. Per the README, dropping a Jar, Zip, ClassFile or Android file starts the decoding process automatically, after which you pick decompilers under View Pane > View 1, View 2 and so on, and open a class from the resource list. There is also a search pane in the left-hand bottom corner.

For scripting, BCV exposes a command line interface. The README lists the flags, including -i for the input file, -o for the output, -t for the target classname, and -decompiler to choose the engine, with procyon as the default. Run -list to display the available decompilers and -help for the full menu, rather than assuming the names match the GUI labels. The README notes that -t must be either a fully qualified classname or "all" to decompile all as zip, and that -nowait skips waiting for the user to read the CLI messages.

## Where Bytecode Viewer stops being the right tool

The command line interface is a decompile-and-exit path, not an automation framework. There is no documented batch mode that walks a directory of jars, no documented machine-readable output format, and no documented exit-code contract. If your goal is to decompile ten thousand artifacts in CI and diff the results, BCV is the wrong shape. The GUI is the product; the CLI is a convenience.

Memory is the second constraint, and it is structural rather than incidental. The README has a dedicated section for java.lang.OutOfMemoryError with the -Xmx3G remedy, which tells you large jars and APKs are expected to strain the default heap. Loading every class into a ClassNode list for plugins makes that worse by design.

Platform friction is the third. The README documents two java.io.FileNotFoundException cases: one on a jar file, fixed by right-clicking, opening Properties, and selecting Unblock under Security on the General tab; and one on an APK, fixed by running BCV as administrator. Those are Windows-specific workarounds, and the fact that they are in the README at all means users hit them often enough to be worth documenting. There is no documented equivalent for macOS or Linux permission problems.

The README also does not document rollback, plugin API versioning, or what happens to a plugin when the underlying ASM version changes. If you write plugins, treat them as pinned to the BCV version you built against.

## Bytecode Viewer versus jadx, and why the difference matters

The comparison people search for is bytecode viewer versus jadx, and the honest answer is that they overlap but are built on different assumptions. JADX appears in BCV's own decompiler list, so BCV is partly a wrapper around the same engine rather than a rival to it.

The difference is in the surrounding structure. BCV is a multi-engine workbench: six decompilers, three disassemblers, two assemblers, two APK converters, plus Dex2Jar and Enjarify, all reachable from one window with up to three panes visible at once. Its value is the comparison and the plugin surface. A single-engine tool that does one job well gives you one reconstruction and no second opinion.

That cuts both ways. A focused decompiler usually has a cleaner command line, better scripting hooks and fewer moving parts to install. BCV's breadth is also its weight: more bundled components means more version coupling, and the README's "Latest dependencies (incl. decompilers like CFR, JD-GUI etc.)" line means the engines move with the project rather than independently.

If you already know which decompiler reads your target correctly, the single-engine route is simpler. BCV earns its place when you do not know yet, or when the artifact is obfuscated enough that you need to triangulate.

## Licence, build cost and what upgrading actually involves

BCV is GPL-3.0. The README links to the licence and labels it "Copyleft". The practical consequence is that if you embed BCV or a derivative in something you distribute, the copyleft terms travel with it. Bundling the jar as an internal analysis tool and bundling it inside a shipped product are different situations, and the second one needs a licence review rather than an assumption. I am not giving legal advice here; the point is that the licence is a real constraint on adoption, not a formality.

Building from source is documented as a single Maven command:

```bash
mvn package
```

The README says to clone the repo and run that, and that working on the source means opening the Maven project, for example opening pom.xml as a project file in IntelliJ. The repository layout matches that: pom.xml, src/, libs/, plugins/, install/, plus checkstyle.xml and checkstyle_suppression.xml at the top level, which suggests style checks run as part of the build and can fail it.

Upgrade cost is the part the README is quiet about. Releases are tagged with "In-Dev" in the title, the newest being v2.13.2 on 2026-01-01, and the README's install instructions still reference the 2.10.x filename. There is no documented migration guide, no changelog file at the top level, and no stated compatibility policy for plugins across versions. If you depend on a plugin you wrote, budget time to re-verify it against each new release rather than assuming it carries over.

## Conclusion

Adopt Bytecode Viewer if you need to read Java or Android bytecode and want several decompilers in one window without assembling a toolchain yourself. Do not adopt it if you need an automated pipeline, a headless batch decompiler, or a permissively licensed component inside a closed product, since the project is GPL-3.0. Before relying on it, verify that the release jar runs on your JDK, that the decompiler you intend to trust produces readable output for your specific target, and that the CLI flags you script against match the version you downloaded.

## FAQ

### How do I install Bytecode Viewer?

Download the latest release from the project's GitHub releases page and run the jar, launching it from the command line if a double click does not work. The README gives the form java -jar Bytecode-Viewer-2.10.x.jar, with the X replaced by the current minor version. There is no documented package manager installation.

### How do I use Bytecode Viewer to open a jar or APK?

Drag the Jar, Zip, ClassFile or Android file into the window and BCV starts decoding automatically. You then choose decompilers under View Pane > View 1, View 2 and so on, and open a class from the resource list. Up to three decompilers can be shown side by side.

### What is Bytecode Viewer?

It is a Java and Android reverse engineering suite written in Java, described in the README as a lightweight bytecode viewer and decompiler. It bundles six decompilers, three disassemblers, two assemblers and two APK converters behind one desktop interface. It is licensed GPL-3.0.

### Bytecode Viewer versus jadx: what is the difference?

JADX is one of the six decompilers BCV bundles, so BCV includes it rather than replacing it. The difference is structure: BCV puts multiple decompilers and disassemblers in one window for side-by-side comparison, while a single-engine tool gives you one reconstruction and a simpler command line.

### How do I install Bytecode Viewer on Kali Linux?

The README documents no Linux-specific installation path, only downloading the release jar and running it with java -jar. The two file permission workarounds it lists (Unblock in Properties, and running as administrator) are Windows-specific, so there is no documented Kali procedure to follow.

## Sources

- [Konloch/bytecode-viewer on GitHub](https://github.com/Konloch/bytecode-viewer)
- [License: GPL-3.0](https://github.com/Konloch/bytecode-viewer/blob/master/LICENSE)
- [Project website](https://bytecodeviewer.com)
- [README](https://github.com/Konloch/bytecode-viewer/blob/master/README.md)
- [Releases](https://github.com/Konloch/bytecode-viewer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/konloch-bytecode-viewer