Decompile JAR online

Q: How do I decompile a JAR file online?

Drop the `.jar` on the page. It opens as a package tree in your browser; click any `.class` to read its decompiled Java, or press **Decompile all classes** in the toolbar to download every source as a single zip. No Java install, no account, and the jar is never uploaded.

Q: Can I download all decompiled sources at once?

Yes. The **Decompile all classes** toolbar button batch-runs the decompiler over the jar and downloads a ` -decompiled.zip` with one `.java` per top-level class, inner classes folded into their outer class, package structure preserved.

Q: Does it decompile Spring Boot jars?

Yes, in layers. Your application classes sit under `BOOT-INF/classes` and decompile directly. Dependencies are nested jars under `BOOT-INF/lib` — click one and choose **Add to zip list** to open it as its own archive, then decompile it too. WAR files work the same way via `WEB-INF/classes`.

Q: What is the difference between a jar decompiler and a jar extractor?

A **jar extractor** unpacks the archive: you get the stored files — compiled `.class` bytecode, the manifest, resources — unchanged. A **jar decompiler** goes further on the class files, reconstructing readable `.java` source from the bytecode so you can actually read the logic. If you want the files out, see [extract a JAR online](/extract-jar-online); if you want to read the code, you are in the right place.

Drop a .jar, click any class to read its decompiled source, or download all of them as a zip — entirely in your browser.

Drop your .jar anywhere on this page

The jar is unpacked and decompiled locally. Your code is never uploaded — only the engine is downloaded, once.

A JAR is a zip of compiled .class files, and decompiling it means reconstructing readable Java for those classes. You usually reach for this when the source is not available: a third-party library behaving strangely, a vendor jar you need to integrate against, a plugin whose docs are gone, or your own code after the source repo was lost. ZipTool opens the jar as a file tree, decompiles any class you click, and can batch-decompile the whole archive into a downloadable zip of .java files — all in the browser tab.

The batch runs on CFR, a battle-tested open-source decompiler, executing on a WebAssembly JVM inside this page. The first decompile fetches the engine once (about 10–20 MB, cached afterwards); your jar is read, unpacked, and decompiled on your device — the exact opposite of the "upload your jar, we email you the sources" sites. For single class files see decompile a class file online; for the general tool, the Java decompiler page; and if it is the files you want rather than the source, extract a JAR online unpacks it in the same tab.

How to decompile a JAR in your browser

Drop the jar, read the code, download what you need.

Drag the .jar onto the page (or browse, or paste a URL). The package tree renders instantly — no Java install, no upload.
Click any .class in the tree. Its decompiled source opens in the viewer with syntax highlighting, and a Download .java button hands you the single file.
For everything at once, click Decompile all classes in the file-tree toolbar (it appears automatically for jars). CFR runs across the archive and you get one <name>-decompiled.zip containing every reconstructed source, package folders included.
Non-class entries (MANIFEST.MF, .properties, XML configs) open directly as text — no decompilation needed for those.

Batch output: what you get in the zip

CFR folds each class’s inner classes and anonymous classes into the file of their outer class — Main$1.class and Main$Callback.class both land inside Main.java — because that mirrors how they were written in the original source. module-info.class and package-info.class are skipped; they are metadata, not code. So the zip contains one .java per top-level class, laid out in the original package structure.

If the jar is obfuscated or damaged, some classes may fail while the rest succeed. The tool reports "N of M classes decompiled" honestly instead of pretending the run was complete, and the zip contains everything that worked.

Spring Boot jars, WARs, and nested archives

A Spring Boot executable jar is not a flat jar: your classes live under BOOT-INF/classes/, dependency jars live under BOOT-INF/lib/*.jar, and the whole thing is launched by a nested loader. ZipTool handles this in two steps. Open the fat jar and decompile your own classes under BOOT-INF/classes directly; for a dependency, click its .jar entry and choose Add to zip list — the nested jar opens as its own archive in the sidebar, ready to browse and decompile. WAR files (a servlet-container sibling with classes under WEB-INF/classes) work the same way.

This layer-by-layer opening is byte-exact: the nested jar is read out of the parent archive in memory, never written anywhere. It also works for .ear enterprise archives and for jars nested inside any supported container (zip, 7z, tar.gz, …).

Your jar does not leave the browser

Jars you want to decompile are rarely jars you want to hand around — closed-source dependencies, client builds, code under NDA. Upload-based decompilers put that file on their servers before showing you anything. Here the jar is opened by a zip parser, the classes are decompiled by CFR on a WebAssembly JVM, and the zip you download is assembled in memory — all inside your tab.

The one-time engine fetch (~10–20 MB) downloads engine *code* from its CDN; it never carries your jar or any class bytes. After the engine is cached, decompiling works fully offline — drop DevTools’ Network tab open alongside a jar to see for yourself. More on the model in why client-side is safer than uploading.

Honest limits

Real capability, stated plainly.

Decompiled source is a reconstruction. Comments, formatting, and most local variable names do not exist in bytecode and cannot be restored. Debug-compiled jars (the norm) recover variable names and generics; release-stripped or obfuscated jars do not.
Big jars take time. Thousands of classes can take minutes on the first batch run; progress is shown and later runs reuse the warm engine. Browser memory bounds how large a jar is practical — tens of MB of classes is fine, multi-hundred-MB monsters are not.
The engine downloads once. First decompile on a slow link can take a while (~10–20 MB); afterwards it is cached and every jar opens fast.
Decompiling is not running. The bytecode is parsed, never executed — but if you later run an untrusted jar with java -jar, that runs on your machine. Read first, run only if satisfied (security and privacy).

Credits

Decompilation by CFR 0.152 (MIT, Lee Benfield), running on CheerpJ by Leaning Technologies under their free Community license. Both arrive as code from their sources; neither sees your jar.

Frequently asked questions

How do I decompile a JAR file online?

Drop the .jar on the page. It opens as a package tree in your browser; click any .class to read its decompiled Java, or press Decompile all classes in the toolbar to download every source as a single zip. No Java install, no account, and the jar is never uploaded.

Can I download all decompiled sources at once?

Yes. The Decompile all classes toolbar button batch-runs the decompiler over the jar and downloads a <name>-decompiled.zip with one .java per top-level class, inner classes folded into their outer class, package structure preserved.

Does it decompile Spring Boot jars?

Yes, in layers. Your application classes sit under BOOT-INF/classes and decompile directly. Dependencies are nested jars under BOOT-INF/lib — click one and choose Add to zip list to open it as its own archive, then decompile it too. WAR files work the same way via WEB-INF/classes.

What is the difference between a jar decompiler and a jar extractor?

A jar extractor unpacks the archive: you get the stored files — compiled .class bytecode, the manifest, resources — unchanged. A jar decompiler goes further on the class files, reconstructing readable .java source from the bytecode so you can actually read the logic. If you want the files out, see extract a JAR online; if you want to read the code, you are in the right place.

Is my jar uploaded anywhere?

No. The jar is parsed and decompiled entirely in your browser tab by CFR running on a WebAssembly JVM. The only network fetch is the engine itself (one-time, ~10–20 MB, cached) — code, not your file. You can verify in DevTools, or decompile with the network disconnected once the engine is cached.

Why do some classes fail to decompile?

Usually obfuscation or non-standard bytecode (some build tools and Kotlin/Scala output stress decompilers). CFR decompiles what it can and the tool reports "N of M" honestly; the zip contains every source that succeeded. Heavily obfuscated jars yield correct-but-unreadable names like a.java — that is inherited from the obfuscation, not a bug.