Java decompiler online
Drop a .jar or a .class file and read the decompiled Java — CFR running on a WebAssembly JVM in your tab, nothing uploaded.
Drop your .jar or .class anywhere on this page
Decompilation runs entirely in your browser. The only download is the engine itself — your code never leaves your device.
A Java decompiler turns compiled bytecode back into readable Java source. You give it a .class file (or a whole .jar of them) and it reconstructs classes, methods, and control flow as close to the original source as the bytecode allows. It is the standard way to understand a library whose source you do not have, audit what a third-party jar actually does, or recover code you compiled and lost.
Most "online java decompiler" sites work by uploading your jar to their server, decompiling it there, and sending the result back. ZipTool does the opposite: the page loads CFR — a widely used open-source decompiler — onto a WebAssembly JVM that runs inside your browser tab, and your code is decompiled on your own device. Nothing you drop here is transmitted anywhere; the only network fetch is the engine itself, downloaded once (about 10–20 MB) and then cached. For packaged classes, see decompile a JAR online; for single files, decompile a class file online.
How to decompile Java in your browser
No JDK, no IntelliJ, no upload. Drop the file and read the source.
- Drag a
.jar(or a bare.class) onto this page, or click to browse, or paste a URL. The archive opens as a file tree, entirely in-browser. - Click any
.classentry. The decompiler reconstructs its Java source, which opens in a code viewer with syntax highlighting. The first class you open also fetches the engine (one-time, ~10–20 MB); after that, each class takes about a second. - Need everything? The Decompile all classes button in the file-tree toolbar runs CFR across the whole jar and downloads one
.zipof the reconstructed sources. - Download any single source with the Download .java button in the viewer. Original file bytes and decompiled sources stay in your tab the whole time.
What decompilation can and cannot recover
Compilation is lossy, and it helps to know exactly what is lost. When javac compiles a .java file, the things that survive into bytecode are the *semantics*: class, field, and method names (unless obfuscated), types, and the exact behavior of the logic. The things that do not survive are everything human: comments, formatting, and local variable names (these become var1, var2, … unless debug info is embedded).
CFR reconstructs source that is semantically equivalent — it compiles back to the same behavior — and it is good enough to read, audit, and port. Generic type information and variable names are recovered when the class was compiled with debug information (the standard -g default in most builds), which most real-world jars are. What you get is a faithful reconstruction, not the author’s original file. Decompiled code is also not automatically re-compilable in edge cases (synthetic constructs, heavy obfuscation).
Obfuscated jars are the honest weak spot: name-mangling (a.class, b.java) and control-flow obfuscation decompile to source that is technically correct but deliberately hard to read. The decompiler still runs; the output just inherits the obfuscation.
Why client-side matters for a decompiler
A decompiler is the one tool where the upload question is sharpest. The jar you want to inspect is often exactly the jar you would rather not hand to a third party: proprietary code under NDA, a client’s build, an APK-equivalent of a paid product, or a file whose safety you are not yet sure of. On an upload-based site, the file you are inspecting *because you do not trust it* is shipped to an unknown server first.
Here the decompiled source is produced on your machine. You can verify that claim yourself: open DevTools (F12), switch to the Network tab, and drop a jar — you will see the one-time engine fetch, and no request carrying your file. Once the engine is cached you can even disconnect from the network entirely and keep decompiling. See why client-side is safer than uploading for the general case.
Honest limits
Real capability, real boundaries — stated up front.
- The engine downloads once (~10–20 MB). Decompiling needs a JVM plus CFR, fetched the first time you open a class and then cached by your browser. On a slow connection the first class can take a while; every class after that is fast.
- Decompiled ≠ original source. Comments, formatting, and most local variable names are lost at compile time and cannot be restored. What you get is a clean, semantically equivalent reconstruction. Heavily obfuscated code decompiles to hard-to-read-but-correct source.
- Reading is safe; running is not. Decompiling never executes the bytecode. If you take a class file out and *run* it, that is a different risk decision — see security and privacy.
- Browser memory is the ceiling. Very large jars (tens of thousands of classes) are slow in a tab; the batch download is streamed as a zip but the engine holds intermediate state in memory.
Credits
The decompiler is CFR 0.152 by Lee Benfield, MIT-licensed, running unmodified. The Java runtime is CheerpJ by Leaning Technologies, whose free Community license lets it run from their CDN inside this page. Both are loaded as code; neither receives your files.
Frequently asked questions
How do I decompile Java online?
Drop a .jar or .class file onto the page. The file opens as a tree in your browser; click any .class and its decompiled Java source opens in the viewer. Use the toolbar’s Decompile-all button to get every class as a zip of .java files. Nothing is uploaded — the decompiler runs on a WebAssembly JVM in your tab.
Does this Java decompiler upload my code?
No. That is the difference between this and most online decompilers: your jar or class file is read, decompiled, and displayed entirely in your browser. The only download is the engine itself (CFR plus a WebAssembly JVM, ~10–20 MB, fetched once and cached). Verify it in DevTools: the Network tab shows no request containing your file.
Which decompiler does it use?
CFR 0.152, a mature open-source decompiler (MIT license) known for clean output on modern Java features — lambdas, generics, and Java 8+ constructs. It runs unmodified, on a WebAssembly JVM (CheerpJ) inside the browser.
Does it work as a jar decompiler?
Yes — jars are the main use case. Drop a .jar, click any class to read its decompiled source, or batch-decompile the whole jar into one zip of .java files. See decompile a JAR online for the jar workflow, including Spring Boot’s nested BOOT-INF jars.
Can a decompiler recover the original source code?
Not exactly. Compilation discards comments, formatting, and (usually) local variable names, and no tool can bring those back. A decompiler reconstructs source that is *semantically equivalent* — same behavior, readable structure. When the class was compiled with debug info (most release jars are), variable names and generics survive and the result is very close to the original.
Is it safe to decompile a jar?
Decompiling itself is safe here: the bytecode is parsed and never executed, and the file stays in your browser. What you do next is the real question — *running* untrusted Java (e.g. java -jar) executes it on your machine with your permissions. Read the code first; run it only if you trust what you read.
Is this free?
Yes — decompiling classes and jars here is completely free, with no account, no install, and no per-file limit. The engine download is one-time and cached by your browser.