Decompile Java .class files to readable source code directly in your browser. View class structure, fields, methods, and bytecode.
Drop a .class file here or click to upload
Drop a .class file onto the upload area or paste hex-encoded bytecode.
The decompiler parses the class file and reconstructs Java source code automatically.
Toggle 'Show bytecode' to see JVM instruction disassembly inside method bodies.
Copy the decompiled source or download it as a .java file.
Reads Java class file format including constant pool, fields, methods, attributes, and exception tables.
Disassembles JVM bytecode instructions with symbolic operand resolution from the constant pool.
Generates readable Java source with package declarations, class hierarchy, field types, and method signatures.
All decompilation runs locally in your browser. Your class files and proprietary code never leave your device.
Unlike server-based decompilers that upload your class files for processing, this tool runs entirely in your browser using JavaScript. Proprietary bytecode, internal libraries, and sensitive application code stay on your machine. No data is transmitted, logged, or stored on any server — ideal for corporate environments with strict data handling policies.
No JDK installation, no IDE plugins, no command-line tools. Drop a .class file and get decompiled source in milliseconds. The tool works on any device with a modern browser — desktop, laptop, or tablet — making it perfect for quick inspections when you do not have a full development environment available.
Toggle bytecode mode to see the actual JVM instructions alongside the reconstructed source. Each opcode is annotated with constant pool references resolved to human-readable class names, method signatures, and literal values. This level of detail is invaluable for performance analysis, security auditing, and understanding how the compiler translates Java constructs.
The parser handles class files from every major Java version, correctly reading constant pool entries including MethodHandle, InvokeDynamic, Module, and Package tags introduced in newer releases. Whether you are analyzing a legacy J2EE archive or a modern Spring Boot microservice, the tool handles it.
Every Java program is compiled by javac into one or more .class files containing bytecode — a platform-independent intermediate representation that the Java Virtual Machine (JVM) interprets or JIT-compiles at runtime. Decompilation reverses this process, transforming bytecode back into human-readable Java source code. Understanding how this works is essential for security auditors, library maintainers, and developers debugging opaque third-party dependencies.
A class file begins with the magic number 0xCAFEBABE, followed by minor and major version numbers that identify the Java release used to compile it. Next comes the constant pool — a table of strings, class names, method signatures, numeric literals, and bootstrap method references that every other structure in the file indexes into. The constant pool is the single most important structure for decompilation because it provides the symbolic names that make bytecode readable.
After the constant pool, the file declares the class's access flags (public, final, abstract, interface, enum), the class and superclass names, and implemented interfaces. Then come the fields and methods tables, each entry containing access flags, a name, a type descriptor, and a list of attributes. The most important attribute is Code, which holds the actual bytecode instructions for a method.
JVM bytecode operates on a stack machine. Instead of registers, operands are pushed onto and popped from an operand stack. Instructions like iload_1 push a local variable onto the stack; iadd pops two integers, adds them, and pushes the result. Method invocations (invokevirtual, invokestatic, invokeinterface, invokedynamic) pop arguments from the stack, call the target method, and push the return value.
Branch instructions (ifeq, goto, tableswitch) control flow by jumping to different bytecode offsets. A decompiler reconstructs high-level control structures (if/else, for, while, switch) by analyzing these branch patterns — a process called control flow analysis.
Java bytecode retains far more metadata than native machine code. Class names, method names, field names, and type descriptors are all stored in the constant pool as plain strings. When compiled with debug information (javac -g), local variable names and line number tables are also preserved. This rich metadata makes it relatively straightforward to reconstruct the original source structure.
javac translates lambda expressions, generics, try-with-resources, and pattern matching into bytecode.Comments are never stored in bytecode and cannot be recovered. Formatting, whitespace, and import ordering are lost. Variable names are only available when debug info is present. Obfuscation tools (ProGuard, R8) rename classes and methods to meaningless identifiers, inline code, and restructure control flow, making decompiled output harder to read — though the logic remains functionally equivalent.
Each new Java release introduces language features that the compiler translates into bytecode using patterns that decompilers must recognize. Lambda expressions (Java 8) compile to invokedynamic instructions referencing bootstrap methods that generate functional interface implementations at runtime. Records (Java 16) produce classes with auto-generated equals, hashCode, and toString methods. Sealed classes (Java 17) add PermittedSubclasses attributes. Pattern matching for instanceof (Java 16) and switch expressions (Java 14) produce intricate branch patterns that a decompiler must reconstruct into their high-level forms. Understanding how these features appear in bytecode helps developers interpret decompiled output from modern Java applications and recognize compiler-generated code that does not correspond to anything explicitly written in the source.
The constant pool is the heart of every class file and deserves closer examination. It is a heterogeneous array of tagged entries, each with a type tag and type-specific data. CONSTANT_Utf8 entries store raw strings — every class name, method name, descriptor, and string literal ultimately references a Utf8 entry. CONSTANT_Class entries reference a Utf8 entry containing a fully qualified class name. CONSTANT_MethodRef combines a class reference and a NameAndType entry (method name plus descriptor) to identify a specific method. CONSTANT_InvokeDynamic entries, added in Java 7 for the invokedynamic instruction, reference a bootstrap method in the BootstrapMethods attribute. The decompiler resolves all these cross-references to produce human-readable class names, method signatures, and literal values in the output. A class file with a corrupt or truncated constant pool cannot be decompiled because every other structure depends on it.
No. All decompilation runs 100% in your browser using JavaScript. Your .class files never leave your device. No data is transmitted, logged, or stored on any server.
The tool supports class files from Java 1.1 (major version 45) through Java 24 (major version 68), covering all constant pool tag types including MethodHandle, InvokeDynamic, Dynamic, Module, and Package.
Variable names are only available if the class was compiled with debug information (javac -g). Without debug info, the tool generates placeholder names like arg0, arg1. Method and field names are always preserved in the constant pool.
Yes, the tool can parse and decompile obfuscated class files. However, the output will contain obfuscated identifiers (e.g., a.b.c instead of meaningful names). The bytecode logic is always fully recoverable regardless of obfuscation.
Disassembly converts bytecode into human-readable JVM instructions (like javap -c). Decompilation goes further, reconstructing high-level Java source code with class declarations, method signatures, and type information. This tool provides both — toggle 'Show bytecode' to see the disassembly.
This tool processes individual .class files. To decompile a JAR, first extract it (a JAR is a ZIP archive), then upload individual .class files. Each .class file corresponds to one Java class.
The tool accurately reconstructs class structure, field declarations, method signatures, and exception handlers. It shows bytecode disassembly with resolved constant pool references. For full source-level decompilation with reconstructed control flow, consider pairing this with offline tools like CFR or Procyon.
Yes. Once the page is loaded, the decompiler works entirely offline with no internet connection required.
The tool accepts Java .class files (binary format starting with 0xCAFEBABE) and hex-encoded bytecode pasted directly into the text area. It does not accept .java source files or .jar archives directly.
Decompilation for interoperability, security research, and personal learning is generally legal in most jurisdictions. The EU Software Directive and US fair use doctrine provide protections. However, always check your local laws and any license agreements that may restrict reverse engineering of specific software.