ZIP to ZIP

How to Convert ZIP to ZIP (Recompress, Merge, or Split)

1. Upload Your ZIP File(s): Click "+ Add Files" or drag and drop one or more ZIP archives onto the dropzone. Drop multiple ZIPs at once if you want to merge them.
2. Pick the Combine Mode: Under "Combine?" choose Single Archive to merge all uploaded files into one ZIP, or Individual Archives to produce a separate ZIP per source file. Default is "Individual Archives" when converting from an existing archive.
3. Confirm Output Format (Optional): The output extension is locked to .zip. If you want a smaller archive, switch to a stronger format on a sibling page — see ZIP to 7z or ZIP to TAR.GZ below.
4. Convert and Download: Click "Convert." The original ZIP is extracted, the contents are repacked with DEFLATE compression, and the new archive is delivered to your browser. No watermark, no sign-up.

Why Convert ZIP to ZIP?

A ZIP-to-ZIP conversion is not a no-op. The tool extracts the source archive(s) entirely, then writes a brand-new ZIP using fresh DEFLATE compression and a clean central directory. That's useful in several specific situations:

• Recompress a "stored" archive. ZIP files created with method 0 (Store) hold the raw bytes uncompressed — common when a script does zip -0 or when an archive was assembled by software that skips compression. Repacking with DEFLATE can shave 30-60% off text-heavy archives (logs, JSON, CSV, source code) while leaving already-compressed media essentially unchanged.
• Merge multiple ZIPs into one. Drop several .zip files in, pick Single Archive, and the contents are extracted and combined into one output. Saves the manual extract-then-rezip cycle.
• Split one ZIP into per-file ZIPs. Use Individual Archives when the source contains many independent items — each top-level entry becomes its own ZIP, handy for bulk distribution.
• Clean up a damaged central directory. When the archive's index is malformed but the local file headers are intact, repacking writes a fresh directory that all ZIP tools can read. Note: this is not deep recovery — heavily corrupted DEFLATE streams still won't extract.
• Strip extended attributes and resource forks. A ZIP made on macOS Finder often contains __MACOSX/ folders and .DS_Store files. Repacking through a clean pipeline drops the macOS-specific cruft when you re-upload elsewhere (note: this tool repacks contents as found; if you need filtered output, extract first locally).
• Normalize compression for sharing. A ZIP with a mix of methods (DEFLATE, BZIP2, LZMA) may not open in older Windows Explorer, which only supports DEFLATE and STORE. Re-archiving forces every entry to plain DEFLATE — the universally supported method.

ZIP Format Quick Facts

Combine Mode Cheat Sheet

Frequently Asked Questions

Will my ZIP actually get smaller after re-archiving?

Only if the original used weak compression. ZIPs created with Store (compression method 0) or low DEFLATE levels can shrink 20-60% on text content. Archives that already hold images (JPG, PNG, WebP), video (MP4, MKV), or audio (MP3, AAC) at their default compression won't shrink meaningfully — those formats are already compressed and DEFLATE has almost no extra signal to find. Expect <5% reduction on a media-heavy ZIP.

How do I merge multiple ZIP files into one?

Drag every .zip file into the upload area at once, or add them with successive "+ Add Files" clicks. Set "Combine?" to Single Archive. The tool extracts each input archive and writes one merged output ZIP. If two source archives contain a file with the same path, the later one overwrites the earlier — rename inside one ZIP first if you need both copies.

Can it repair a corrupted ZIP file?

Partly. If the central directory at the end of the archive is damaged but the per-entry local file headers and DEFLATE streams are intact, repacking produces a clean, readable archive. If the data itself is truncated, contains CRC errors, or the DEFLATE stream is broken, repacking can't reconstruct the missing bytes — for that you need a dedicated recovery tool that does multi-engine extraction.

Will repacking remove password protection?

Yes. The tool needs to read the contents to repack them; if the source ZIP is encrypted, you must supply the password during extraction. The output ZIP is written without encryption unless you explicitly add it. If your source uses ZipCrypto (the legacy weak cipher) and you re-share the output as plain DEFLATE, you've also dropped the obscurity layer — make a deliberate decision before sending the result anywhere sensitive.

Why would I split one ZIP into individual archives?

Two common cases. First, distribution: each recipient only needs one of the items, and you'd rather hand out 20 small ZIPs than one large one. Second, file-size limits: some upload endpoints reject any ZIP over a fixed cap, and per-file ZIPs may each fall under the threshold. For arbitrary size-based splitting (e.g., split a 4 GB ZIP into 200 MB volumes), you need a multi-volume splitter — that's not what "Individual Archives" does here; it splits per top-level entry.

What compression level does the output ZIP use?

The output uses standard DEFLATE compression. DEFLATE supports levels 0-9 in the zlib reference implementation, where 0 stores uncompressed and 9 is maximum compression at the cost of CPU. The tool picks a balanced default — the actual output size is typically within a few percent of zip -9 for the same input. If you need maximum compression for archival, convert to ZIP to 7z instead; LZMA in 7z routinely produces 20-40% smaller archives than DEFLATE on the same content.

Will the file timestamps and folder structure survive?

Folder structure and relative paths are preserved exactly. Modification timestamps stored in the ZIP local header are also carried through. Note that ZIP only stores DOS-format timestamps with 2-second resolution by default; sub-second precision and creation/access times stored in extra fields (UT, NTFS) may be normalized depending on how the source ZIP recorded them.

Why does my ZIP open on Windows but not on older Linux unzip?

Probably because the source archive uses a non-DEFLATE compression method (BZIP2, LZMA, Zstandard) that the older unzip binary doesn't support. The InfoZIP unzip package shipped on many Linux distributions only handles Store and DEFLATE. Repacking through this tool forces the output to plain DEFLATE, which works on every ZIP-aware tool back to PKZIP 2.0 (1993).

Are there alternative archive formats I should consider?

For maximum compression, use 7z (LZMA2) — see ZIP to 7z. For Linux/Unix workflows that need POSIX permissions and symbolic links preserved, use TAR.GZ — see ZIP to TAR.GZ or ZIP to TAR.XZ. For Windows-native sharing where the recipient definitely has WinRAR, ZIP to RAR is fine but RAR is proprietary. ZIP remains the right pick whenever broad compatibility matters more than ratio.