Convert ZIP to ZIP Online (Rebuilding an Archive With Different Settings)

What Actually Happens When a ZIP Gets Rebuilt Into Another ZIP

A ZIP file is PKWARE's 1989 archive container, defined in the public APPNOTE.TXT specification, which still gets revised today (the current release is version 6.3.9). Every entry inside carries its own local header and compressed data, and a central directory at the end of the file lists every entry's name, size, and byte offset. Rebuilding a ZIP as a ZIP means fully unpacking that structure and reassembling a new one from scratch — new local headers, freshly written compressed data, and a newly generated central directory — rather than copying the old file byte for byte.

That rebuild step matters because a surprising amount can differ between two ZIP files that both open and extract identically. The ZIP specification allows several distinct compression methods (stored/uncompressed, DEFLATE, and, through the WinZip/7-Zip extension, AES encryption recorded as method 99), several different encryption schemes with real security differences, and either a single-file or multi-volume split layout. Two ZIPs holding the exact same files can differ in any of those respects, and going from one configuration to another is the entire point of a ZIP-to-ZIP conversion.

Legacy ZipCrypto Encryption Compared With the AES Extension

The ZIP specification's original password protection, known as ZipCrypto, has been part of the format since early versions and is supported by essentially every ZIP tool ever built. It is also cryptographically weak by current standards — security researchers and password-recovery tool vendors have documented that a ZipCrypto-protected archive can be broken in a matter of minutes on ordinary hardware, using a known-plaintext attack that exploits weaknesses in its stream cipher design, not a brute-force password guess.

AES-256 encryption for ZIP files isn't part of PKWARE's core specification; it's an extension originally introduced by WinZip and now supported by 7-Zip, WinRAR, PeaZip, and other current tools, recorded internally using compression method 99 rather than the plain DEFLATE or stored methods. Rebuilding an existing ZipCrypto-protected ZIP into an AES-256-protected one requires decrypting the original archive first, which means the original password has to be known — there's no way to upgrade a ZIP's encryption without it, since the file contents are genuinely unreadable without that password to begin with. Once decrypted, the same files get rebuilt into a new ZIP with the stronger AES scheme applied and, ideally, with the "encrypt filenames" option enabled too, since some AES-ZIP implementations still leave the file list itself readable in the central directory unless that option is turned on explicitly.

What Rebuilding a ZIP Can Change and What It Can't

• Gain — real encryption instead of weak encryption: rebuilding with AES-256 in place of ZipCrypto closes a well-documented cracking method that affects the older scheme specifically.
• Gain — a cleaner file list: ZIPs built by macOS's Archive Utility or Finder often bundle a __MACOSX folder holding a duplicate resource-fork copy of every file, plus scattered .DS_Store files — a rebuild can drop both, which is purely cosmetic clutter with nothing else depending on it.
• Gain or lose size, depending on direction: switching the compression method from stored (no compression) to DEFLATE shrinks the archive; switching from DEFLATE to stored trades size for the CPU time DEFLATE would otherwise spend on data that's already compressed, like photos or videos.
• Gain — a single-volume archive from a split one, or the reverse: the ZIP spec supports splitting an archive into fixed-size volumes (originally for floppy disks, now mainly for email or upload size limits), and a rebuild can merge those parts back into one file or split a single large ZIP into parts.
• Lose — nothing about the actual file contents: a straightforward re-archive doesn't change the underlying files themselves, only the container's compression, encryption, and structural settings around them.
• Lose — unneeded ZIP64 overhead on small archives: some tools apply ZIP64's larger 64-bit fields by default even to archives well under the 4 GB/65,535-file thresholds; a rebuild targeting the plain (non-ZIP64) format avoids the rare older reader that mishandles ZIP64 headers unnecessarily.

Which Tools Actually Support Each of These Re-Archiving Changes

AES-256 encryption for ZIP files is read and written by 7-Zip, WinRAR, WinZip, and PeaZip, and Windows 11 gained the ability to extract (not create) AES-256-encrypted ZIPs starting with the 23H2 update — earlier Windows versions and File Explorer's older built-in ZIP support only understand ZipCrypto, so an AES-encrypted archive rebuilt for stronger security will fail to open on those systems without a separate tool. This is a real, specific compatibility trade to weigh: the more secure scheme requires more current software.

Splitting or merging multi-volume ZIP archives is supported directly in 7-Zip and WinZip's split-archive features, and in the command-line Info-ZIP tools with a specified split size. Removing the __MACOSX folder and .DS_Store entries can be done by simply deleting those specific entries from the archive with any ZIP manager, or by rebuilding from a fresh set of source files that excludes them in the first place — either approach produces a functionally identical archive for the actual content, just without the macOS-specific extras.

The ZIP specification's per-volume size limit is 4 GB (2^32 minus 1 bytes), and a multi-volume archive can hold up to 65,535 parts, giving a theoretical total archive size well into the hundreds of terabytes across all volumes combined. In practice, split sizes are chosen for a specific limit somewhere else in the chain, such as an email provider's attachment cap or a removable media size, rather than approaching the format's own much larger ceiling.

The Real Reasons People Rebuild an Already-Zipped File

A common, well-documented complaint is a Windows user receiving a ZIP created on a Mac and finding it full of unwanted __MACOSX and .DS_Store entries that clutter the extracted folder — every file appears duplicated once as itself and once inside __MACOSX, since that folder holds a resource-fork copy of each original entry. This isn't file corruption; it's how macOS's own zip and Archive Utility behave by default, and rebuilding the archive without those specific entries resolves the complaint completely.

A second real scenario involves security audits or compliance reviews flagging archives protected only with ZipCrypto, given documented tools that can recover a ZipCrypto password in minutes — the remediation in these cases is specifically to re-encrypt the affected archives with AES-256 rather than treat the existing password protection as adequate, since the underlying weakness is in the cipher itself, not the password's strength.

A third scenario shows up around email and upload limits: a single large ZIP that exceeds an email provider's attachment cap or a web form's upload ceiling gets rebuilt as a set of split volumes, each under the size limit, sent or uploaded separately, and reassembled by the recipient's ZIP tool once all the parts are present — a workaround built directly into the ZIP specification's own multi-volume support rather than a third-party trick.

Common ZIP-to-ZIP Rebuild Scenarios Side by Side

Questions About Rebuilding an Already-Zipped Archive

Why would I convert a ZIP to another ZIP instead of just leaving it alone?
Because the container format staying the same doesn't mean everything inside it stays the same — encryption method, compression method, and whether the archive is split into volumes can all change while the file is still, technically, a ZIP.

Can I upgrade a password-protected ZIP from ZipCrypto to AES without knowing the password?
No. The archive has to be decrypted first, which requires the original password, before it can be rebuilt with AES-256 encryption applied. There's no way to change the encryption scheme of a ZIP whose contents can't currently be read.

Will an AES-encrypted ZIP open on every computer that opens regular ZIPs?
Not universally. Older Windows versions and File Explorer's legacy built-in support only recognize ZipCrypto; AES-256 support was only added for extraction in Windows 11's 23H2 update, so older systems need a separate tool like 7-Zip.

How do I get rid of the __MACOSX folder that keeps showing up in ZIPs from Mac users?
Rebuild the archive while excluding entries under __MACOSX and any .DS_Store files — both are safe to remove entirely since they're macOS-specific metadata, not part of the actual content being shared.

Does re-compressing a ZIP change the files inside it?
No. Changing the compression method, encryption scheme, or split structure of a ZIP doesn't alter the actual file data once it's extracted — a photo, document, or script comes out byte-for-byte identical regardless of which of these container-level settings were used to store it.