Extract a JAR online
A .jar (Java ARchive) is a ZIP container wearing a different extension — its bytes start with the same PK signature, and its payload is compiled .class files, META-INF/MANIFEST.MF, and bundled resources laid out as a folder tree. Extracting (or unzipping, or decompressing — same operation) a jar means unpacking that tree into real files, and because a jar is a zip, any zip tool can do it — including this one, in your browser, with no JDK and no upload.
ZipTool opens the .jar locally, renders the package tree in the tab, and writes the contents out when you extract — to a folder you choose on Chrome and Edge, or as a clean zip download on Firefox and Safari. One thing worth knowing before you start: extraction gives you `.class` bytecode, not source code. The classes come out as compiled binary files that a text editor cannot read. If what you actually want is to *read the Java*, the same tool can decompile the jar to readable source — also in your browser. The two operations are one click apart, and this page covers extraction.
How to extract (decompress) a JAR in your browser
No jar xf, no JDK, no WinRAR — the jar is unpacked in your tab.
- Add the .jar. Drag it onto the page, pick it from disk, or paste a direct URL. The bytes are read locally — nothing is uploaded.
- Browse the package tree. Folders mirror the Java package names (
com/example/app/…), and you can search the whole archive by name. Click any entry to preview it: the manifest,.properties, XML and YAML configs open as text; images and PDFs render inline. - Extract everything. The extract-all control in the file-tree toolbar unpacks the whole jar — on Chrome and Edge it writes the real folder structure to a directory you pick, elsewhere it downloads the contents bundled as a zip.
- Or take single files. Preview an entry and download just that file when one
.classor one config is all you need.
Extract versus decompile: which one do you need?
The distinction trips up almost everyone searching for a jar tool, so it is worth thirty seconds. Extracting unpacks the archive: you get the original files as they are stored — .class bytecode (binary), the manifest, resources. Nothing is translated; a signer’s jar comes out byte-for-byte as it went in. Decompiling goes further on the class files: it reconstructs readable .java source from the bytecode, so you can actually read the logic. Extraction answers "what is in this jar and how is it organized"; decompilation answers "what does this code do".
Both are one click apart here. Extract the jar with the toolbar control as described above; when you find yourself staring at unreadable .class files, click any of them and ZipTool decompiles it to Java in place — or use the toolbar’s decompile-all button to get every source as a zip. For the format background, see what is a JAR file and what is a class file.
The usual ways to unzip a jar (and why a browser works too)
On a machine with a JDK installed, the canonical command is jar xf app.jar (extract files). Because a jar is a standard zip, the generic unzip app.jar does the same on any system with unzip, and most archive managers (7-Zip, The Unarchiver) open jars natively. Rename a copy to .zip and even the tools that refuse a .jar extension happily unpack it.
The browser route is for the cases those do not cover: a machine where you cannot install anything (locked-down work laptop, chromebook, someone else’s computer), a quick look before bothering with a terminal, or a jar you would rather not save to disk at all. ZipTool needs no install and no Java runtime — it parses the zip container locally in the tab.
Privacy: jars are usually somebody’s code
A jar you want to extract is rarely a random download — it is a vendor library, a client’s build, code under NDA, or a plugin you are evaluating. Upload-based "jar extractor" sites put exactly that file on their servers before showing you anything. Here the jar is read, listed, and unpacked entirely in your browser tab; no server ever receives a copy.
The claim is checkable, not a promise to take on faith. Open DevTools (F12), watch the Network tab while you drop and extract the jar — you will see the page load and no request carrying your file — then disconnect from the network and confirm browsing and extracting still work. See why client-side is safer than uploading for the general case.
Spring Boot jars and nested archives
A Spring Boot executable jar is a jar inside a jar’s clothing: your classes live under BOOT-INF/classes/, dependency jars under BOOT-INF/lib/*.jar, and the loader stitches them together at runtime. Extracting the fat jar unpacks that structure as-is — you get the folders and every nested .jar as a file. To look inside 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, extract, or decompile. WAR files work the same way via WEB-INF/.
This layer-by-layer opening happens in memory — the nested archive is read out of its parent without being written anywhere first.
Honest limits
Extraction here is the real pipeline, with the boundaries that come with running in a tab.
- Extracted `.class` files are bytecode, not source. That is what extraction means; use the in-browser decompiler when you want readable Java.
- Browser memory is the ceiling. The tab holds the entry list and unpacked output; very large jars (hundreds of MB) are slower and heavier than a desktop unzip.
- Extraction does not verify signatures. A signed jar’s
META-INFsignature files come out like any other file; unpacking does not check or preserve the seal (repacking would break it anyway). - Reading is safe; running is not. Extracting and previewing never executes the code — but
java -jaron an untrusted jar runs it on your machine. See security and privacy.
Frequently asked questions
How do I extract a JAR file online?
Drag the .jar onto the page. It opens as a package tree entirely in your browser; use the extract-all control in the toolbar to unpack everything (to a folder on Chrome and Edge, as a zip download elsewhere), or preview an entry and download single files. No JDK, no install, and the jar is never uploaded.
Can I decompress or unzip a jar without Java installed?
Yes. A jar is a standard ZIP container — its bytes start with the same PK signature — so unzipping it needs no Java runtime at all. ZipTool reads the zip container directly in your browser and unpacks it locally; the command-line equivalents (jar xf, unzip) work too but require a JDK or unzip installed.
What is the difference between extracting and decompiling a jar?
Extracting unpacks the archive: you get the stored files — compiled .class bytecode, the manifest, resources — unchanged and unreadable as text. Decompiling additionally reconstructs readable .java source from those class files. Extract to get the files out; decompile to read the code. ZipTool does both in the browser — see decompile a JAR online.
Does it work on Spring Boot jars?
Yes. Your application classes sit under BOOT-INF/classes and extract 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 extract or decompile it too. WAR files behave the same way through WEB-INF/.
Is my jar uploaded anywhere?
No. The jar is parsed and unpacked entirely in your browser tab. Verify it in DevTools (F12 → Network) — no request carries your file — or extract with the network disconnected after the page loads, which still works. For jars that are proprietary or under NDA, that is the difference that matters.