FfFilenameFixer
← All articles

Zip Files on Mac for Windows Users Without Broken Names

If you zip files on Mac for Windows users and they reply that the names look wrong (José shows as "Jose" with a stray mark, 한글 breaks into ㅎㅏㄴㄱㅡㄹ, or Excel says the file does not exist) the archive itself is fine. Two Mac habits cause it: macOS often stores accented and Korean/Japanese filenames in a decomposed Unicode form (NFD) that Windows does not expect, and the Finder's Compress command adds a hidden __MACOSX folder with ._ copies of every file. The fix on the sending side is to normalise the names to NFC before compressing, then build the ZIP with a tool that leaves out the Mac metadata. This article covers that order of operations, plus what to do if the archive has already gone out.

Why a ZIP you made on a Mac shows broken names on Windows

There are three separate things going on, and it helps to know which one you are looking at.

Decomposed characters (NFD). macOS has a long history of writing filenames in NFD, where "é" is stored as "e" followed by a separate combining accent, and a Korean syllable is stored as its individual jamo. Windows, most web servers and most Windows programs expect the composed form (NFC), where "é" is a single character. Windows Explorer will usually still draw an accented letter, but the name is technically different from what you typed. That is why a colleague can see José_invoice.xlsx on screen and still get "file not found" when a macro, a script or a SharePoint link looks for the NFC spelling. Korean and Japanese names are more obvious: the syllables visibly fall apart, and dakuten split from their kana (が becomes か plus ゛).

The __MACOSX folder and ._ files. When you right-click and choose Compress in the Finder, macOS stores resource forks and Finder metadata as ._filename entries inside a __MACOSX folder. Windows has no use for these. They are harmless, but they double the file count, confuse people who think the ._ files are corrupted versions, and get flagged by some upload forms.

Encoding, not normalisation. If the names come through as José or a run of question marks, that is a different problem: the extraction tool on the Windows side read the names with the wrong character set. Modern Windows Explorer and 7-Zip handle UTF-8 ZIP names created by current macOS, so this mostly happens with very old unzip utilities. This article does not solve that one; it is about NFD and the extra folder.

Zip files on Mac for Windows: the steps

Do these in order. Fixing the names after compressing means re-doing the archive, so normalise first.

1. Check whether your names are actually NFD

You cannot see NFD in the Finder. Two quick ways to check:

  • Open Terminal, cd into the folder, and run ls | python3 -c "import sys,unicodedata; [print(repr(n)) for n in sys.stdin.read().splitlines() if unicodedata.normalize('NFC', n) != n]". Any name printed is NFD.
  • Or copy a filename from the Finder's Get Info window and paste it into the text converter on the FilenameFixer web app. If the converted text differs from what you pasted, the name is decomposed.

Plain ASCII names (report_2026.pdf) are never affected. Only accented Latin letters, Hangul, kana with dakuten/handakuten and similar characters matter.

2. Normalise the names to NFC

On a Mac with an APFS drive (every Mac with macOS 10.13 or later on its internal disk), a renamed file keeps the form you give it. Options:

  • Batch rename in the browser. Drag the files onto the FilenameFixer web app, review the before/after list, and download the renamed files. Processing happens locally in your browser; nothing is uploaded. This is the easiest route for a mixed folder of documents from Korean or Japanese colleagues.
  • Terminal, one line. In the folder, run python3 -c "import os,unicodedata; [os.rename(n, unicodedata.normalize('NFC', n)) for n in os.listdir('.') if unicodedata.normalize('NFC', n) != n]" This renames only the top level of the current folder, so repeat it in subfolders or extend it with os.walk if you are comfortable doing so.
  • Homebrew users can install convmv and run convmv -f utf8 -t utf8 --nfc -r --notest . on the folder.

Caution: on an HFS+ volume (older Macs, or an external drive formatted "Mac OS Extended") the filesystem forces NFD again, so renaming will appear to do nothing. Skip to the section on fixing the finished ZIP instead.

3. Compress without the __MACOSX folder

The Finder's Compress command always adds the metadata folder. Use one of these instead:

  • Terminal with zip: zip -r -X archive.zip FolderName. The -X flag strips extended attributes. If you also want to leave out .DS_Store files, use zip -r -X archive.zip FolderName -x "*.DS_Store".
  • Terminal with ditto: ditto -c -k --norsrc --noextattr FolderName archive.zip. This is Apple's own tool and produces a clean, Windows-friendly ZIP.
  • Keka (free third-party archiver) has an option under Preferences to exclude Mac resource forks; turn it on before compressing.

Both zip and ditto write UTF-8 names with the correct flag set, so current Windows Explorer and 7-Zip read them correctly.

4. Verify before sending

Run unzip -l archive.zip in Terminal. You should see your files and folders only, no __MACOSX line and no ._ entries. If you want to be thorough about NFD, pipe that listing through the Python check from step 1.

If the ZIP already went out, or your drive is HFS+

Sometimes the archive has already been sent, or you are on an HFS+ volume where renaming does not stick. In both cases you can fix the names inside the finished archive instead of touching the source files.

The ZIP filename restore tool takes an archive of up to 200 MB, rewrites every NFD entry name to NFC, and gives you a corrected ZIP to download. The file contents are untouched and the processing stays in your browser. Send the corrected archive as a replacement, or ask the recipient to run the original through the same page on their side. It does not remove the __MACOSX folder, so if that matters, re-create the archive with ditto or zip -X as described above once you have normalised names.

If you would rather avoid tools entirely, the Windows recipient can simply retype the affected filenames after extracting. For a handful of files that is quicker than anything else. For a folder of two hundred Korean-named documents it is not.

What to tell your Windows colleague

A short note saves a lot of back-and-forth. Something like:

  1. Extract with the built-in "Extract All" in Explorer or with 7-Zip; both read Mac-made ZIPs correctly.
  2. Delete the __MACOSX folder if there is one. The ._ files inside it are not damaged copies, just Mac metadata.
  3. If a program still cannot open a file whose name looks correct, the name is in decomposed form. Rename it by hand, or drop the extracted files on the FilenameFixer web app to batch-rename them.

Developers on the receiving end can confirm the cause with PowerShell: [Text.Encoding]::UTF8.GetByteCount("José") returns 5 for the NFC spelling and 6 for NFD. Node, Python and .NET all expose normalize("NFC") if a script needs to accept both forms.

Limits and related problems that look similar

  • Long paths. Windows limits full paths to 260 characters unless long-path support is enabled. Deeply nested Mac folders with long names can fail to extract regardless of normalisation. Shorten the top-level folder name before zipping.
  • Archives over 4 GB need ZIP64; zip and ditto on current macOS handle this, but some older Windows tools do not.
  • Password-protected ZIPs created with zip -e use legacy encryption, which 7-Zip opens but Windows Explorer does not. Not a filename issue, but it produces similar "it does not work on Windows" emails.
  • Reserved characters. Names containing :, ?, *, |, <, > or " are legal on macOS but not on Windows, and Explorer will refuse or rename them on extraction. NFC normalisation does not change these; you have to replace them yourself.
  • Round trips. If the Windows user edits files and sends a ZIP back, nothing breaks: NFC names are preserved on APFS. The problem only runs in the Mac-to-Windows direction.

Normalise first, compress with ditto or zip -X, check the listing, and the "broken names" replies stop. If the archive is already in someone's inbox, rewriting the names inside the ZIP is the quickest replacement you can send.