What is a JAR file?

JAR structure: what is actually inside

Because a JAR is a ZIP, its layout is a plain directory tree of files. The parts that matter:

The compiled bytecode lives as .class files, placed in directories that mirror the Java package names. A class declared as com.example.app.Main compiles to com/example/app/Main.class inside the JAR. This mirroring is how the JVM locates a class by its fully qualified name.

META-INF/MANIFEST.MF is the manifest, a plain-text metadata file at the root of the archive. It holds Name: value entries grouped into a main section and optional per-entry sections. The attributes that matter most are Main-Class (which class to run for an executable jar), Class-Path (relative paths to other jars to load onto the classpath), version information (Specification-Version / Implementation-Version), and Sealed (package sealing). An executable JAR is simply one whose manifest sets Main-Class.

Bundled resources sit alongside the classes: .properties and .yaml config files, .xml descriptors, localised message bundles, images, fonts, or whatever the application needs at runtime. These are loaded through the classloader as classpath resources.

For signed JARs, META-INF/ also contains signature files. There is a .SF file (the signature list) plus a .RSA or .DSA block file carrying the PKCS#7 signature from the signer's certificate. The .SF holds a digest of the manifest and a digest for each manifest entry; the block file signs the .SF. Their presence is what lets the runtime verify the archive was not altered after signing.

How the JVM uses a JAR

A JAR on the classpath is how Java code is shipped and loaded. When you compile against a library, you are really adding its jar to the classpath so the classloader can resolve classes by package path.

To run an executable jar, you point the launcher at it: java -jar app.jar. The JVM opens the archive, reads Main-Class from META-INF/MANIFEST.MF, loads that class, and invokes its main(String[]) method. The manifest's Main-Class attribute is therefore the difference between a runnable application jar and a plain library jar.

For a library, you instead add it with -cp / -classpath (for example java -cp lib/app.jar com.example.app.Main) and name the entry class yourself. Either way the archive stays packaged; the classloader reads entries out of it on demand.

How to open or run a JAR file

Running an executable jar requires a Java runtime (JRE or JDK) installed. On the command line: java -jar app.jar. If nothing happens, the usual causes are a missing or malformed Main-Class in the manifest, or a bytecode version mismatch (the jar was compiled for a newer Java than your runtime supports).

• Command line: java -jar app.jar for an executable jar; java -cp app.jar com.example.Main for a library jar where you name the class.
• Desktop: on some operating systems double-clicking a .jar runs it via javaw -jar if a JRE is registered for the extension, but this is unreliable and OS-dependent.
• Inspect only (do not run): treat the .jar as a ZIP and list or extract it. See the next section.
• In-browser preview: open the JAR in ZipTool to browse the package tree and read the manifest, .properties, and XML configs without a Java runtime and without uploading the file.

How to inspect a JAR's contents

Since a JAR is a ZIP, you do not need Java to look inside it. Two standard ways to list the contents:

Use jar tf app.jar (the JDK's own tool, which prints every entry) or the generic unzip -l app.jar (works on any system with unzip). Both show the directory tree, the manifest, and every bundled resource.

Or open the file in an in-browser viewer like ZipTool. You can browse the package tree exactly as it sits in the archive and preview the text-based resources directly: MANIFEST.MF, .properties files, XML and YAML configs. Because parsing happens entirely in your browser tab, the archive is never uploaded to a server.

One honest limit: .class files are compiled bytecode, not source. They are not human-readable text, so a viewer can show you the structure and every non-class resource, but it cannot show readable Java for the classes themselves. For that you would need a decompiler, which is a separate and heavier step.

Sibling formats: WAR and EAR

Two JAR-derived formats turn up in Java server code. They use the same ZIP container and the same manifest conventions, just with extra layout rules.

WAR (Web Application aRchive) packages a web application for a servlet container like Tomcat, Jetty, or WildFly. It adds a defined structure (WEB-INF/classes for compiled classes, WEB-INF/lib for dependency jars, and WEB-INF/web.xml or annotation-based config) and is deployed by dropping it into the container rather than run with java -jar.

EAR (Enterprise aRchive) is the larger sibling that bundles multiple WARs and EJB JARs for a full Java EE / Jakarta EE application server. You will rarely see one outside enterprise deployments, but it follows the same principle: a ZIP with a manifest and a prescribed directory layout. See the archive formats overview for where these sit next to APK, EPUB, OSGi bundles, and other ZIP-based formats.

Security: signed JARs and untrusted code

Signing is how the Java ecosystem proves a JAR came from a known source and was not modified afterwards. The .SF plus .RSA/.DSA files in META-INF let the runtime verify the archive against the signer's certificate and fail closed if a single byte has changed. Treat a valid signature as evidence of origin, not as evidence that the code is safe to run.

The important distinction here is privacy versus security. Inspecting a JAR in an in-browser viewer like ZipTool is a genuine privacy improvement: the file contents never leave your browser, there is no upload, no server copy, and no storage. That much is real. But client-side processing is not a guarantee that nothing bad can happen. A malicious JAR is still a malicious JAR. If you then execute it with java -jar, the Java code inside runs on your machine with your user's permissions, and that code can do anything any other program can.

So: opening a JAR to look at it is low-risk, but running a JAR from an untrusted source is not. Do not execute jars from sources you cannot verify, and do not rely on the browser sandbox to protect you after you have moved the file onto disk and run it with Java. Read more in security and privacy.

Frequently asked questions