ZIP Files Created on Windows Won't Extract on Mac (and Vice Versa)

ZIP Files Created on Windows Won’t Extract on Mac (and Vice Versa)

A ZIP file that opened cleanly on the system that created it but produces garbled filenames, mysterious __MACOSX folders, or extraction failures on a different operating system is rarely corrupt. The archive itself is intact — the problem is that ZIP’s filename encoding has been ambiguous since the format was designed in 1989, and different tools on different platforms make different assumptions about how to read it.

Quick fix

The single most reliable fix for cross-platform ZIP problems is to use a competent third-party archive tool instead of the operating system’s built-in handler.

On Windows, install 7-Zip. Right-click the ZIP and choose 7-Zip → Extract Here (or Extract to folder). 7-Zip respects the UTF-8 flag in modern ZIPs and falls back gracefully on older ones. Windows Explorer’s built-in ZIP support is limited and produces garbled filenames for any ZIP not created on the same Windows code page.

On macOS, install The Unarchiver (free, from the Mac App Store) or Keka. Both handle a wider range of encodings than Finder and let you specify an encoding manually when filename detection fails. Finder’s built-in ZIP handler is reasonable for most modern archives but mishandles older Windows-created files.

On Linux, the standard unzip command from Info-ZIP can specify the source encoding directly:

unzip -O CP437 archive.zip

-O sets the character encoding to use for filenames. Common values are CP437 (the original DOS encoding assumed by older ZIP tools), CP1252 (Windows Western European), and UTF-8. Note that the -O flag is part of Info-ZIP unzip — it is not present on every system’s unzip (the BSD variant doesn’t have it).

For most cross-platform problems, switching tools resolves the symptom without needing to understand the underlying encoding mismatch.

If that didn’t work

If switching archive tools didn’t help, the next step depends on the specific symptom.

Filenames appear as ?????? or random characters. The ZIP doesn’t have the UTF-8 flag set and your extraction tool is guessing the wrong encoding. On Linux, retry with unzip -O <encoding> and try CP437, CP1252, and Shift_JIS in turn. On Windows, 7-Zip’s File Manager has a Tools → Options → Code Page setting that affects extraction. On macOS, The Unarchiver lets you choose an encoding manually under Preferences → Encoding.

Extraction produces a __MACOSX folder and .DS_Store files everywhere. The ZIP was created by macOS Finder, which includes resource fork data and metadata files. These are harmless on any system but visually noisy. After extraction, delete the __MACOSX folder and any .DS_Store files. On Linux or macOS, this one-liner cleans them up:

find . -type d -name "__MACOSX" -exec rm -rf {} + && find . -name ".DS_Store" -delete

Extraction fails partway with a “path too long” error on Windows. Some Windows file systems and applications still enforce a 260-character path limit. Either extract to a shorter directory path (C:\temp\ rather than C:\Users\YourName\Documents\Projects\Archive\), or enable Windows long path support via Group Policy or registry on Windows 10 1607 or later. 7-Zip handles long paths regardless of the system setting.

Symbolic links from a Linux or Mac ZIP don’t extract on Windows. Windows doesn’t natively support the symlink mode used by Unix archive tools. The links are usually silently dropped during extraction. If the archive depends on symlinks, extract on a Linux or Mac system instead.

Advanced recovery

If you control the source — that is, you’re the one creating the ZIP — the fix is to produce an archive that works cleanly on all systems.

When creating a ZIP on macOS for cross-platform use, exclude the macOS-specific metadata explicitly:

zip -r archive.zip folder -x "*.DS_Store" -x "__MACOSX/*"

The -x flag specifies patterns to exclude. The two patterns above remove the metadata files Finder includes by default. The result is a clean ZIP that extracts identically on Windows, Mac, and Linux.

When creating a ZIP that contains non-ASCII filenames, ensure your archive tool produces a UTF-8 ZIP. 7-Zip on Windows and Keka on Mac both default to UTF-8 for new archives. Recent macOS Finder versions use UTF-8 with the appropriate flag set. Older Windows tools and the legacy zip command on some systems may not — verify by extracting your test archive on a system with a different default encoding before distributing.

For one-off conversion between encodings, the convmv tool on Linux can rename files in place to fix mojibake post-extraction:

convmv -f CP437 -t UTF-8 -r --notest broken-named-folder/

-f is the from-encoding, -t is the target, -r recurses, and --notest actually performs the renames (convmv defaults to a dry run). This is useful when you’ve extracted a ZIP and now have a directory full of garbled names that you can’t easily re-extract.

Why this happens

The ZIP format was published by PKWARE in 1989, designed for DOS, and assumed all filenames would be encoded in CP437 — the original IBM PC character set. CP437 covers basic Latin characters plus a small set of European accented characters and box-drawing symbols. Anything outside that set was undefined behavior.

For about fifteen years this didn’t matter much. Then international filenames became common, and ZIP tools across different platforms started inventing their own conventions for encoding non-ASCII characters. Windows tools tended to use the system’s current code page (CP1252 for Western Europe, Shift_JIS for Japan, GBK for Simplified Chinese, and so on). Unix tools tended to use UTF-8 or the system locale. The same byte sequence in a filename meant entirely different characters depending on which system created the archive and which extracted it.

In 2007, ZIP specification version 6.3.0 added a formal solution: bit 11 of each entry’s general purpose flag indicates that the filename is UTF-8 encoded. Modern archive tools set this flag when creating archives with international filenames, and modern extraction tools check it. The catch is that older archives don’t have the flag, older tools don’t read the flag, and the operating system’s built-in ZIP handlers vary considerably in how rigorously they implement the modern behavior.

The macOS metadata problem is unrelated. macOS files historically had a “data fork” containing the actual file contents and a “resource fork” containing metadata, type codes, and similar information. When Finder creates a ZIP, it stores resource forks in a parallel __MACOSX/ folder structure inside the archive, with each metadata file prefixed ._. Other operating systems have no concept of resource forks, so they extract these as ordinary content — visible, useless, and slightly confusing. The .DS_Store files Finder scatters in directories serve a similar purpose for storing folder display preferences.

Preventing this in future

If you regularly share ZIPs across operating systems, standardize on a tool that produces clean, UTF-8 encoded archives without OS-specific metadata. 7-Zip on Windows, Keka on Mac, and the standard zip command on Linux all work well when configured to exclude metadata.

If you’re creating ZIPs programmatically, prefer libraries that explicitly support UTF-8 filenames: Python’s zipfile module from version 3.6 onward, Java’s ZipOutputStream with a UTF-8 charset, .NET’s System.IO.Compression.ZipArchive with the UTF-8 entry name encoding option.

For user-facing distribution where you can’t control the recipient’s tools, stick to ASCII filenames inside the archive when practical. ASCII names work identically on every system regardless of encoding flags.

Related issues

For the related symptom of ZIPs that simply won’t extract at all, see the guide to ZIP extraction failures partway through. For ZIPs damaged in transit rather than encoded for the wrong platform, see incomplete ZIP downloads. The archive repair complete guide covers the structural foundations of ZIP and the related formats that share these encoding quirks.

Last verified: April 2026