Convert JAR to ZIP Online (What Survives When Java Metadata Is Stripped)

A JAR File Is a ZIP File With One Extra Required Entry

Sun Microsystems introduced the JAR (Java ARchive) format in 1997 to package compiled Java classes and resources for distribution. It did not invent a new container. A JAR uses the exact same local file headers, the same DEFLATE or stored compression, and the same end-of-file central directory as a plain ZIP archive. Any ZIP-reading tool, including Windows Explorer or 7-Zip, can already open a .jar file just by treating it as a .zip.

What actually makes a JAR a JAR is a single required file: META-INF/MANIFEST.MF. The Java specification requires this manifest to be the first entry stored in the archive. It is a plain-text file using name-value pairs modeled on the RFC 822 email header format, and it can declare things like which class contains the program's entry point (the Main-Class attribute), which other JAR files the program depends on (Class-Path), and whether specific packages are "sealed" so all their classes must come from the same archive. Converting a JAR to ZIP does not touch the underlying compression at all — it is really a decision about whether that manifest and everything tied to it gets kept, stripped, or left to rot unreadable inside a file nobody built to look for it anymore.

Why the Manifest's Position Inside the Archive Matters

Java provides two different ways to read a JAR's contents, and they do not treat the manifest the same way. The java.util.jar.JarFile class works like a random-access ZIP reader: it can jump straight to the central directory and find META-INF/MANIFEST.MF no matter where it sits in the archive. The java.util.jar.JarInputStream class instead reads entries in order, front to back, and it only recognizes the manifest if it is literally the first entry in the file. If a general-purpose ZIP tool rebuilds the archive and reorders the entries — alphabetically, for instance, which many archivers do by default — JarInputStream-based code returns a null manifest even though the exact same bytes are sitting untouched somewhere later in the file.

Code signing makes the stakes higher. Running the jarsigner tool on a JAR adds a signature file (META-INF/<ALIAS>.SF) and a signature block file (META-INF/<ALIAS>.RSA or .DSA) into the archive. These files store cryptographic digests computed over each entry's exact compressed bytes. If a converter fully unpacks and rebuilds the archive — which is what recompressing to a different compression setting actually does — even one changed byte, one re-ordered entry, or one altered timestamp invalidates every digest in the .SF file. The signature files can still be present in the resulting ZIP, technically readable as text, while being completely unable to verify anything, because what they were signing no longer exists in that exact form.

What a Plain ZIP Keeps From the Original JAR and What It Drops

• Keep — every .class file and resource, byte for byte: compiled classes, images, property files, and any other resource extract identically, since the underlying ZIP compression never changes.
• Lose — the ability to run it with "java -jar": that command specifically looks for META-INF/MANIFEST.MF's Main-Class attribute to know what to launch; a converter that strips or breaks the manifest leaves a file that opens fine but won't start as a program.
• Lose — verifiable code signatures on any rebuild: as covered above, the .SF and signature block files depend on exact byte-level digests that a fresh compression pass invalidates.
• Lose — the Class-Path attribute's meaning: the manifest's Class-Path entry tells the JVM where to find dependent JARs relative to this one; a plain ZIP extractor has no idea this attribute means anything and just leaves it as inert text.
• Gain — universal recognition by every ZIP-only tool and workflow: some corporate file filters, upload portals, and mail scanners specifically block or flag .jar attachments as executable content, while treating .zip as an ordinary archive.
• Keep — the directory structure exactly: package hierarchies (like com/example/app/Main.class) stay intact as folder paths inside the archive, since that structure is just the ZIP entry names, unrelated to the manifest.

How Real Java Tooling Reacts to a Renamed or Rebuilt JAR

The Java Development Kit's own jar tool, and IDEs like IntelliJ IDEA and Eclipse, all read archives through the JarFile-style random-access path by default, so a JAR that still contains its original manifest — just wrapped in different compression settings — will usually still be recognized as valid by these tools even after conversion. The problem shows up specifically in code that uses JarInputStream for streaming reads, which includes parts of some application server classloaders and custom deployment scripts that process JARs as they download rather than after they're fully saved to disk.

Archive utilities like 7-Zip, WinRAR, and the Windows and macOS built-in extractors do not know or care about the Java-specific manifest attributes at all. They will open a converted .zip and show every file inside it correctly, including META-INF/MANIFEST.MF as a plain text file anyone can read. What none of them do is check whether Main-Class points to a valid class, whether the Class-Path resolves, or whether any signature file still matches — those checks only happen inside the Java runtime itself, specifically when something invokes java -jar or a signature-verifying classloader.

The Actual Reports Behind "My JAR Stopped Working After I Zipped It"

A recurring build-tooling complaint involves reproducible-build systems that re-package JARs for deterministic output — Maven and Gradle plugin issue trackers have documented cases where a plugin sorted archive entries alphabetically for reproducibility and, in doing so, moved META-INF/MANIFEST.MF away from the first position, which is precisely the situation that breaks JarInputStream.getManifest() while leaving JarFile-based tools unaffected. The fix documented in these cases is always the same: whatever process rebuilds the archive has to explicitly force the manifest back to the first entry, not just include it somewhere.

A second well-documented pattern involves signed JARs used for applet or webstart-style deployment in older Java environments — once such a JAR gets run through any tool that decompresses and recompresses its contents, even without deliberately touching the manifest, the signature block no longer matches and the JVM refuses to treat the code as signed, sometimes silently falling back to an unsigned security sandbox instead of failing outright. This is described in Java security documentation as expected behavior tied directly to how jarsigner computes its digests, not a conversion bug.

A third pattern is simpler: mail servers and file-upload systems that block executable-looking attachments by extension. Renaming or converting a .jar to .zip is a documented, intentional workaround some IT departments recommend specifically to get a JAR past an attachment filter that treats .jar as a security risk, with the understanding that whoever receives it will rename it back before trying to run it as a program.

What Happens to Each Java-Specific Feature After Conversion

Questions About Turning a JAR Into a Regular ZIP

Can I just rename a .jar file to .zip instead of converting it?
Yes, for reading purposes. Since a JAR already uses the ZIP container format, changing the extension alone lets any ZIP tool open it and extract every file, without needing any actual conversion process at all.

Will the program still run after I convert its JAR to ZIP?
Not through java -jar. That command looks for the manifest's Main-Class attribute specifically inside a file it treats as a JAR; a file saved and referenced as .zip, or one whose manifest has been stripped, won't launch as a Java program even though the class files are still inside it.

Does converting a signed JAR to ZIP keep the digital signature valid?
No, not if the archive gets recompressed. Jarsigner's signature files store exact digests of each entry's compressed bytes, and any rebuild — even one that changes nothing meaningful — produces different bytes that no longer match those digests.

Why does my Java tool say it can't find the manifest after conversion?
Some tools, particularly those using JarInputStream for streaming reads, only recognize META-INF/MANIFEST.MF if it's the very first entry in the archive. If a conversion process reorders entries, that specific class of tool stops finding the manifest even though it's still in the file.

Is a JAR file smaller or bigger than the equivalent ZIP?
Essentially the same size, aside from the small manifest file itself. Both formats use identical DEFLATE compression on the underlying data, so the difference amounts to a few hundred bytes for the META-INF folder, not a meaningful size change.

Why would anyone convert a JAR to ZIP on purpose?
Common reasons include getting past mail or upload filters that specifically flag .jar as executable content, or handing off just the resources and class files to someone who has no interest in running the program and only wants to inspect or reuse what's inside.