Why Accented File Names Break Between Mac and Everything Else (NFC vs NFD)

Quick answer

A file named café.md can exist as two different sequences of bytes that look, print, and search identically — one where "é" is a single character, one where it's an "e" plus a separate accent mark. macOS has historically favored the second form, decomposed. The web, Linux, and Windows favor the first, composed. Compare names byte-for-byte instead of meaning-for-meaning, and an identical-looking file can appear renamed, duplicated, or just missing. The Unicode Standard calls this a normalization mismatch — the same invisible-difference problem behind line endings that silently differ between operating systems. The text reads the same. The bytes don't.

How it actually works

Unicode allows some accented characters to be written two canonically equivalent ways. UAX #15 defines the two forms precisely: NFD (Normalization Form D) fully decomposes a character into a base letter plus combining marks — "é" becomes "e" plus a combining acute accent. NFC (Normalization Form C) starts the same way, then recomposes anything with a single precomposed codepoint, turning "é" back into one character. Both represent the same abstract text — but only a normalizing comparison treats them as equal. A plain byte comparison doesn't. And names made of unaccented ASCII characters? They have no second form, so this never touches them.

macOS inherited its side of this from HFS+, which stored file names on disk in an NFD-like decomposed form — the Finder still decomposes names it writes today. APFS, the filesystem on every current Mac, does better: it preserves whatever normalization a caller supplied and resolves lookups using a hash of the normalized form, instead of forcing everything decomposed on write, as Apple's APFS documentation explains. There's one narrow historical exception worth knowing: very early APFS releases were briefly normalization-sensitive. Create a file under one normalization, open it under another, and you could get ENOENT — "no such file or directory" — for a name that visibly matched.

This is exactly why Git ships a Mac-only setting for it. Say a repository has a file named with an accented character, committed by a Linux or Windows collaborator in NFC. A Mac checkout can write that same file to disk in NFD — and git status will report it as changed or renamed on every subsequent run, even though nobody touched it. Git's `core.precomposeUnicode` option fixes exactly this. Turn it on, and Git reverts macOS's decomposition before comparing, matching the NFC convention Linux and Windows already use. Anyone keeping Markdown notes under version control across machines with non-ASCII file names should flip it on once and never think about it again.

When to use it (and when to skip it)

This isn't a feature to weigh — it's a compatibility fix you either need or don't. You need it if you're sharing repositories or synced folders with accented file names across macOS and Linux or Windows, restoring files from an old HFS+-era backup onto a modern volume, or moving files over older network file-sharing protocols. And the mismatch isn't theoretical. Wikipedia documents a real case where OS X silently renormalized filenames sent over Netatalk and Samba, and the receiving Linux systems didn't recognize the renamed file as the same one. In some configurations, that led to actual data loss.

Skip worrying about it if your file and note names are plain ASCII, if you work on a single device, or if you're syncing entirely within Apple's own ecosystem — iCloud already normalizes internally. Syncing plain-text notes across iPhone, iPad, and Mac purely within Apple's stack keeps this failure mode out of your way. It reappears the moment a non-Apple system, an old backup, or a cross-platform Git remote enters the picture. One catch: normalizing on one end doesn't retroactively fix names already committed elsewhere in the wrong form. That can take a one-time rename pass to clean up.

How Carets fits in

Carets is a fast, native notes and code editor for iPhone, iPad, and Mac — Markdown, plain text, and code in one place, organized into files, projects, and tags. It's native and fast, not a web wrapper bolted onto a browser engine, so your file and note names are handled by the current, consistent filesystem behavior on each device — not a decade of mixed HFS+, APFS, and network-share history. Your files stay plain text underneath. Write an accented file name in Carets on your iPhone, and it opens exactly the same way on your Mac. Get Carets on the App Store for iPhone, iPad, and Mac.

Frequently Asked Questions

Why does a file with an accented name look renamed in Git even though I didn't touch it?

macOS is writing that file name to disk in NFD (decomposed accents), while the copy Git already has recorded — often committed from Linux or Windows — is in NFC (precomposed accents). The two byte sequences render identically but don't match, so Git reports a change. Setting core.precomposeUnicode=true in your Mac Git config normalizes to NFC before comparing, matching what Linux and Windows already do.

Is this still a problem on modern Macs with APFS, or was it only an HFS+ issue?

APFS improved things: it preserves whatever normalization a name was written in and resolves lookups via a hash of the normalized form, so day-to-day access mostly works. But it doesn't rewrite names already stored elsewhere — an old backup, a cloud-sync index, a database column — so mismatches from the HFS+ era, or from other systems that still send NFD, can still surface as duplicate-looking files or "file not found" errors.

Does this affect plain-English file names too?

No. Only characters with both a precomposed and a decomposed Unicode form — accented letters like é, ñ, ü — can end up as two different byte sequences for the same visible name. A file name using only unaccented ASCII characters has no second form to normalize, so it's unaffected.

What's the practical fix if I share files between Mac and Windows or Linux?

Normalize before you compare or store. For Git repositories, turn on core.precomposeUnicode on the Mac side. For general file sync, prefer tools that normalize to NFC on the wire — the convention the web and most non-Apple filesystems already use — rather than assuming both ends agree on raw bytes.

Can I just rename the file to fix it?

Renaming forces the OS to rewrite the name in its current preferred form, which can resolve a one-off mismatch. It doesn't fix the underlying cause — if the same folder keeps moving between systems that normalize differently, the mismatch will resurface on the next file that crosses over.

Conclusion

NFC vs NFD is a byte-level choice you never see — two Unicode-legal ways to spell the same accented character. It only becomes visible when a comparison, a sync, or a git status treats the two forms as different files. The fix isn't changing how a name looks. It's making sure whichever tool is comparing names normalizes first. If accented file names regularly cross between a Mac and anything else, know which side normalizes — and don't leave it to chance.