What is a class file?

Inside a .class file: structure

The class file format is a strictly ordered binary layout, defined by the JVM specification. A reader walks it top to bottom:

• Magic number — the four bytes 0x CA FE BA BE ("cafe babe"). Every valid class file starts with it; it is how tools recognize the format instantly.
• Version numbers — a minor and a major version, two bytes each. The major version maps to the Java language level: 50 = Java 6, 52 = Java 8, 55 = Java 11, 61 = Java 17, 65 = Java 21. A JVM refuses to load bytecode newer than itself — the source of the classic "unsupported class file version" error.
• Constant pool — the class’s table of strings: class and interface names, field and method names, type descriptors, string literals, numeric constants. Everything the class refers to by name lives here once, indexed by number.
• Access flags & declarations — whether the class is public, final, abstract, an interface or enum; then this class, its superclass, and its interfaces (as constant-pool references).
• Fields and methods — each with flags (private, static, final…), a name, a type descriptor, and optional attributes. Method bodies are stored as a Code attribute containing the bytecode instructions.
• Attributes — everything optional-but-important: LineNumberTable and LocalVariableTable (the debug information that lets decompilers recover variable names), annotations, and generic signature data.

Bytecode: instructions for a stack machine

Method bodies are sequences of JVM instructions. Unlike a real CPU, the JVM is a stack machine: instructions push and pop values on an operand stack instead of writing registers. Adding two numbers is iload_0 (push local 0), iload_1 (push local 1), iadd (pop both, push the sum), istore_2 (store into local 2). There are around two hundred opcodes covering loads, arithmetic, field access, method calls, object creation, branches, and exception handling.

Two properties of this design matter in practice. First, it is deliberately verifiable: the JVM checks every method’s bytecode before running it (types line up, stack use is consistent), which is a large part of Java’s memory-safety story. Second, it retains a lot of structure — names, types, and control flow are preserved — which is exactly what makes decompilation to readable source possible at all.

.java, .class, and .jar: the triangle

The three Java file types form a one-way pipeline with a decompiler shortcut back:

A `.java` file is human-written source — plain text, one public class per file by convention. A `.class` file is what javac turns it into: binary bytecode for the JVM. A `.jar` file is many class files (plus resources and a manifest) zipped into one deliverable — what is a JAR file covers that container in depth.

The forward direction (source → class → jar) is compilation and packaging. The backward direction is decompilation: a tool that reads bytecode and reconstructs equivalent Java source. It cannot recover what compilation discarded — comments, formatting, and typically local variable names — but with debug information present (the default for most builds) it gets remarkably close. You can try it without installing anything: decompile a class file online or decompile a whole JAR online, in your browser, no upload.

How to open a .class file

"Opening" a class file means one of two very different things — reading it or running it. Reading is what decompilers and viewers do; running executes it on a JVM. The distinction matters for safety: reading never executes the code, running it does, with all your user permissions.

• Decompile it (read as Java): the practical choice. A decompiler like CFR reconstructs the source; ZipTool runs it in your browser, so the file is not uploaded anywhere.
• Disassemble it (read as bytecode): the JDK’s javap -c Main.class prints the raw instructions — opcode by opcode, useful for compiler-level debugging, not for reading logic.
• Run it: java Main (the class must be on the classpath; for jars, java -jar app.jar reads the manifest’s Main-Class). Only run class files you trust.
• Hex-inspect it: the first bytes should read CA FE BA BE — a quick way to confirm a download is actually a class file before anything else.

Version table: which Java compiled this?

Bytes 4–7 of a class file give its minor and major version. The major version tells you exactly which language level the compiler targeted — handy when a jar refuses to run on an older runtime:

• Java 8 → major 52 · Java 11 → major 55 · Java 17 → major 61 · Java 21 → major 65
• Older but still common: Java 5 → 49, Java 6 → 50, Java 7 → 51
• A JVM loads bytecode with major version ≤ its own. Java 8 runs major-50 classes fine; the reverse fails with UnsupportedClassVersionError.

Security: opening is not running

A class file is data until a JVM executes it. Decompiling, disassembling, or hex-dumping a class file parses bytes — nothing in it runs, so inspecting even a malicious class is safe in itself. That is why "read it before you trust it" is reasonable advice for jars from unknown sources.

The line is crossed when you *run* the code: java -jar on an untrusted jar executes it with your permissions, and the sandbox of the browser you inspected it in is irrelevant at that point. Inspect freely, run cautiously. More in security and privacy.

One privacy note that applies to the tooling itself: many online decompilers ask you to upload the class file to their server. If the code is sensitive — proprietary, under NDA, a client’s build — prefer an in-browser decompiler where the file never leaves your device (decompile class files online).

Frequently asked questions