FfFilenameFixer
← All articles

ZIP File Names Garbled on Windows? Fix a Mac-Made Archive

If you have a ZIP file with names garbled after moving it from a Mac to Windows, there are only two likely causes, and both are fixable without touching the contents of the files. Either the archive stores names in a text encoding Windows reads the wrong way (you see things like José.pdf), or the names are stored in macOS's decomposed Unicode form, so accents and Korean or Japanese syllables arrive split into pieces (Jose´.pdf, ㅂㅗㄱㅗㅅㅓ.docx). The first case is solved by extracting with a different tool; the second is solved by normalizing the names to NFC, which you can do in the browser or with a short PowerShell command. The steps below cover both.

Why ZIP file names get garbled between Mac and Windows

The ZIP format stores each file name as raw bytes plus a small flag that says whether those bytes are UTF-8. The data inside the files is never affected, which is why the documents open fine once you get at them. Only the labels break.

The typical situation looks like this. A colleague on a Mac selects a folder in Finder, chooses Compress, and emails or Slacks you the resulting .zip. You double-click it in Windows Explorer, choose Extract All, and the folder that appears contains names such as:

  • Zoe¨_invoice.xlsx instead of Zoë_invoice.xlsx
  • Jose´ Contract.pdf instead of José Contract.pdf
  • ㅎㅏㄴㄱㅡㄹ.docx instead of 한글.docx
  • か゛いよう.pptx instead of がいよう.pptx

Or, in the other failure mode, something entirely unreadable like José Contract.pdf or 한글.docx.

These are two separate problems that happen to look similar:

Encoding mismatch (mojibake). The archiver wrote UTF-8 bytes but did not flag them as UTF-8, and the Windows extractor interpreted them using the system's legacy code page. You get strings of accented capital letters and symbols that have nothing to do with the original name. The underlying name is intact; it was just decoded wrong.

Decomposed Unicode (NFD). macOS stores many file names with accents and marks as separate code points: é becomes e followed by a combining acute accent, 가 becomes the jamo ㄱ + ㅏ, が becomes か + ゛. The name is technically correct Unicode and Windows will accept it, but Windows, most web forms and most servers expect the composed form (NFC). So the letters render oddly, Explorer search does not find them, scripts that compare file names fail, and upload forms may reject or duplicate them. This is the Jose´ and ㅎㅏㄴㄱㅡㄹ case.

Telling them apart takes ten seconds, so do that first.

Step 1: figure out which problem you have

Open the extracted folder (or just view the ZIP in Explorer without extracting) and look at one of the broken names.

  1. If the name contains characters that are clearly not part of any real word (é, 한, ’), it is the encoding mismatch. Skip to Fix B.
  2. If the name is readable but letters and their accents look slightly detached, or Korean shows as separate consonants and vowels, it is NFD. Confirm with this quick check:
    • Right-click the file and choose Rename.
    • Press End, then Backspace once.
    • If only the accent (or only the vowel/dakuten) disappears and the base letter stays, the name is decomposed. In a normal NFC name, Backspace removes the whole é or the whole syllable.

If you are comfortable with PowerShell, this also tells you directly:

Get-ChildItem -Recurse -File | Where-Object {
  -not $_.Name.IsNormalized([Text.NormalizationForm]::FormC)
} | Select-Object FullName

Any file it lists is in NFD.

Fix A: ZIP file names garbled by NFD (split accents, split Korean)

You have two reasonable options. One works entirely in the browser and keeps the archive as an archive; the other renames files after extraction.

Option 1: repair the names inside the ZIP in the browser

This is the least effort if you want to forward the ZIP to someone else or keep it intact.

  1. Open the ZIP filename restore tool in your browser.
  2. Drag the .zip from your Downloads folder onto the page (archives up to 200 MB are supported).
  3. The tool rewrites the file names inside the archive from NFD to NFC and gives you a corrected ZIP to download.
  4. Extract the new ZIP with Extract All as usual. Names such as José Contract.pdf and 한글.docx now appear correctly, and Explorer search finds them.

The processing happens locally in your browser; the archive and its names are not uploaded to a server, which matters when the ZIP contains client contracts or HR documents. It is free. If you already extracted the files and only have loose files, the same site lets you drag and drop files for batch renaming instead.

Option 2: rename after extracting with PowerShell

Windows ships with everything needed to normalize names; .NET has done Unicode normalization for years. Work on a copy of the folder first, because this renames in place.

  1. Extract the ZIP normally.
  2. Open the extracted folder, click in the address bar, type powershell and press Enter. A PowerShell window opens in that folder.
  3. Paste this and press Enter:
Get-ChildItem -Recurse -File | ForEach-Object {
  $nfc = $_.Name.Normalize([Text.NormalizationForm]::FormC)
  if ($nfc -ne $_.Name) {
    Rename-Item -LiteralPath $_.FullName -NewName $nfc
  }
}
  1. Run it a second time with -Directory instead of -File if folder names are affected too (rename folders after the files inside them, or the paths change under you).

This is a fine approach for one-off cases and for developers who want it in a build script. The downside is that it does nothing about the original ZIP, and it is easy to run in the wrong directory.

Fix B: ZIP file names garbled by an encoding mismatch

If you saw mojibake like José, normalization will not help; the bytes need to be decoded as UTF-8 in the first place.

  1. Install 7-Zip (free, from 7-zip.org) or another third-party archiver. These generally read UTF-8 names correctly even when the UTF-8 flag is missing, which is where Explorer's built-in extractor tends to fall over.
  2. Right-click the ZIP, choose 7-Zip → Extract Here (or Extract to "foldername").
  3. Check the names. If they are now readable, you are done.
  4. If they are readable but accents or Korean syllables are split, you had both problems at once. Go back to Fix A and normalize the extracted files.

If a third-party extractor still produces nonsense, the sender's archiver used a legacy encoding rather than UTF-8. At that point the fastest route is to ask the sender to re-zip. On a Mac, the built-in Compress command and most third-party apps write UTF-8; the trouble is usually an old or unusual tool, or a ZIP that was re-packed on a Windows machine with a different system language.

Avoiding the problem next time

A few habits remove most of this for good, on both sides of the exchange.

If you are the one sending from a Mac: before compressing, you can run the folder through a normalizer so names are already NFC. Or avoid the issue by sharing a cloud-drive link instead of a ZIP; most cloud services normalize names on upload, though not all do, so check once with a test file. For files uploaded through web forms rather than ZIPs, the FilenameFixer Chrome extension converts names to NFC automatically at upload time, which spares the recipient's form validation from rejecting Zoë.xlsx because it does not match the Zoë already in their system.

If you are receiving on Windows: keep 7-Zip or similar installed, and when a Mac-made archive arrives with Korean, Japanese or accented names, run the ten-second Backspace test before you spend time renaming by hand. Renaming by hand is especially unreliable here, because the decomposed and composed names look identical in most fonts, and you will end up with two files that appear to share a name.

If you are a developer: normalize to NFC at the boundary of your application, whether that is a file upload handler, a sync script or a build step. Python's unicodedata.normalize("NFC", name), Node's name.normalize("NFC") and .NET's String.Normalize() all do the job. It is far cheaper than debugging why a test passes on macOS and fails on the Linux CI runner because two "identical" filenames are different byte sequences.

None of this changes the documents themselves, so there is no risk to the contents. The worst outcome of a wrong guess is that you have to extract the archive a second time.