Decompile class files online
Drop a .class file — or a .jar full of them — and read the reconstructed Java source in your browser.
Drop your .class file anywhere on this page
The class file is decompiled locally on a WebAssembly JVM. Nothing is uploaded; the engine downloads once and is cached.
A .class file is compiled Java bytecode — binary, unreadable as text, and impossible to make sense of in a normal editor. Decompiling it reconstructs the Java source the compiler produced it from: class name, fields, methods, and logic, as close to the original as bytecode allows. If you only have the class file — pulled out of a jar, recovered from a build directory, sent by a colleague — a decompiler is how you read it.
ZipTool decompiles .class files in your browser with CFR, running on a WebAssembly JVM. Drag the file in and the reconstructed source opens in a code viewer. The first run fetches the engine once (~10–20 MB, cached); every class after that decompiles in about a second. Your file is never uploaded — unlike upload-based "paste your class here" services. For whole archives see decompile a JAR online; for format background, what is a class file.
How to decompile a .class file
One file, one drag, no JDK.
- Drag the
.classonto the page (or click to browse, or paste a URL). The file is validated locally — a real class file starts with the magic bytesCA FE BA BE. - The decompiled Java source opens in the viewer with syntax highlighting. Read it, search it, copy it.
- Use Download .java in the viewer to save the reconstructed source.
- Have several class files, or a jar? Drop them all — each opens in the tree, and jars additionally offer the batch Decompile all classes button.
CAFEBABE: how a class file identifies itself
Every valid .class file begins with the four bytes 0x CA FE BA BE — the Java team punning on "café babe" — followed by two-byte minor and major version numbers that encode the Java level the file was compiled for. Major 52 means Java 8, 55 means Java 11, 61 means Java 17. That is why a "bad class file version" error appears when you run new bytecode on an old runtime: the version check happens before anything else.
ZipTool uses the magic bytes as the first gate. If a file does not start with CA FE BA BE, it tells you the file is not a Java class instead of feeding garbage to the decompiler — a renamed .txt or a corrupted download fails fast and honestly. (You can still open it as text via the viewer switcher if you want to look at the raw bytes.)
Inside, the version is followed by the constant pool — the class’s table of strings, class references, and method names — then field and method definitions and the actual bytecode instructions. That is precisely the material a decompiler reads to rebuild source. The full anatomy is covered in what is a class file.
One class vs a jar of classes
A loose .class decompiles on its own, with one caveat worth knowing: the source it came from may reference sibling classes (parameters, imports, parent classes). Decompilation still works — CFR reconstructs the class fully — but cross-class references appear as their names because the other classes are not in the room. Drop the enclosing .jar instead and every class is available, which also gives CFR the context it uses to recover generics and exception tables more accurately.
Practically: for one class, drop the class file; for anything bigger, drop the jar and click through the tree. Both paths are local, and the engine is shared — a jar you open after a class file does not re-download anything.
Honest limits
What this can and cannot do, plainly.
- The engine downloads once (~10–20 MB). The first decompile fetches the WebAssembly JVM plus CFR and can take a moment on slow links; it is cached afterwards, and later classes decompile in about a second.
- Reconstructed, not original. Comments, formatting, and most local variable names are gone at compile time. With debug info (the default for most builds) names and generics come back; without them you get
var1,var2, … - Magic bytes are required. A file that does not start with
CA FE BA BEis not a class file and will be rejected — check for corrupted downloads or misnamed files. - Decompiling never executes the code. The class is parsed, not run. Running unfamiliar Java yourself is a separate decision (security and privacy).
Credits
Decompilation by CFR 0.152 (MIT, Lee Benfield) on CheerpJ by Leaning Technologies (Community license). Both load as code; your class file stays with you.
Frequently asked questions
How do I decompile a .class file online?
Drag the .class file onto the page. It is validated in your browser (real class files start with the bytes CA FE BA BE), then decompiled locally and shown as Java source in a code viewer, with a download button for the .java. Nothing is uploaded and no JDK is needed.
Can I open a .class file without uploading it?
Yes — that is exactly how this works. The file is read and decompiled inside your browser tab on a WebAssembly JVM. The only download is the engine itself, once (~10–20 MB, then cached). Check DevTools’ Network tab while opening a class: no request contains your file.
What does CAFEBABE mean in a class file?
It is the class-file magic number: every valid .class starts with the four bytes 0x CA FE BA BE, followed by version bytes that encode the Java level (e.g. major 52 = Java 8). It exists so tools can instantly recognize the format — and why ZipTool can reject a fake .class before wasting your time.
Why does my .class show garbage in a text editor?
Class files are binary bytecode, not text. A text editor shows mojibake because the bytes are not characters. Use a decompiler to read one properly — or, if you want to inspect the raw bytes, open it as text in the viewer switcher here.
Will the decompiled code be the original source?
It will be equivalent, not identical. Names, types, and behavior are recovered (variable names too, when debug info is present — most builds include it), but comments and formatting are gone forever, since they never exist in bytecode. The output is clean, readable Java that behaves the same.