File system

Why macOS ignores capital letters in file names

It sounds academic until a website works perfectly on your Mac and returns a missing file in production.

6 min read

A Mac disk is case insensitive but case preserving. It remembers that you typed Report.pdf and shows it that way, then treats report.pdf as the same file. That is the default on every Mac. A case sensitive option exists. Most people should leave it alone.

The distinction sounds academic until a website works on your Mac and returns a missing file in production.

Insensitive and preserving are two separate promises

Both apply. Confusing them is where the misunderstanding starts.

Preserving means the name is stored exactly as you typed it. Capitals survive, Finder shows them, with nothing quietly lowercased.

Insensitive means the disk does not use case to tell two names apart. Ask for readme.md and you get README.md, because to the disk they are one name.

So one file, displayed the way you wrote it, reachable however you spell it.

The consequence people meet first. Two files called readme.md and README.md cannot exist in the same folder. Unpack an archive from a Linux machine containing both and one silently overwrites the other.

Checking which yours is

Two ways. The second takes seconds.

Disk Utility names the format outright. A volume reading APFS is case insensitive. One reading APFS (Case-sensitive) is not.

Or test it. Make a file called Test.txt, then in Terminal ask for test.txt. If it opens, the volume is case insensitive. If it reports no such file, it is not.

Why Apple chose it

The decision predates macOS and has survived every rewrite since, for one reason. A great deal of Mac software was written and tested against a case insensitive disk. Some of it hardcodes a path with particular capitals. On a case sensitive volume that path fails to resolve and the application breaks in ways that make no sense to whoever is watching.

Apple kept the default rather than break that software. The alternative was correct and expensive.

Where the file system stores these names, as opposed to how it compares them, belongs to the file system itself.

What breaks if you switch

Disk Utility offers a case sensitive APFS format. The list of things that stop working is longer than the documentation suggests.

Steam refuses outright, with an error naming a path it requires on a case insensitive file system. Unreal Engine has the same problem. Adobe applications have historically been unhappy. Installers of all kinds check for it and stop.

None of that is a bug in the file system. It is software that assumed the default and never had reason to find out.

So the startup disk is not the place to experiment. Anything that stops working there stops working for everything you do.

Git notices, then stops noticing

This one costs developers real time and the cause is invisible.

Git detects the file system when a repository is created or cloned. On a Mac it sets itself to ignore case. That is the sensible default, because otherwise every mixed case path would look changed.

The cost is that a rename which only changes case is not a change at all. Rename Common.java to common.java and Git sees nothing to commit. The repository keeps the old name. Colleagues on Linux keep the old name. Your Mac shows the new one, because it preserved what you typed.

Turning the setting off makes Git strict, at the price of phantom changes appearing on a disk that cannot represent them properly. Neither answer is comfortable, which is why the real fix is a naming convention rather than a setting.

The one that reaches production

Web servers run on Linux. Linux is case sensitive.

A page referencing images/Logo.png when the file on disk is logo.png works perfectly on your Mac, because the two names are the same name there. Deploy it and the server looks for exactly what was asked for, fails to find it, then returns nothing.

The image was there the whole time. The Mac was being helpful.

This is the single most common way the default causes a real problem. It stays invisible until deployment, because every local test passes.

The other comparison nobody mentions

Case is not the only thing a Mac disk normalises.

Accented characters can be written two ways. As one character carrying its accent. Or as a plain letter followed by a separate combining mark. On screen they look identical, so macOS treats a file named either way as the same file.

Linux does not. So a filename with an accent can travel to a server, arrive looking exactly right, then fail to match the link pointing at it.

The symptom is identical to the case problem. The cause is not. The fix is the same. Keep filenames to plain lowercase letters, numbers and hyphens for anything a server will serve.

Finding collisions before they find you

One command lists names in a folder that differ only by case.

find . -print | sed 's|.*/||' | sort -f | uniq -di

Anything it returns is a pair the Mac has already collapsed into one. Failing that, a pair waiting to collapse when the project moves to a machine that cares.

The arrangement that works

Leave the startup disk as it is and put the strict work somewhere else.

An APFS container shares its free space between volumes, so adding a case sensitive volume beside the existing one costs nothing until you put something on it. Code lives there, applications live on the ordinary volume, with neither arrangement interfering with the other.

A case sensitive disk image works the same way for anyone who would rather not add a volume.

The alternative, converting the startup disk, requires erasing it and takes the software problems with it. For one project the volume is a better trade.

Common questions

Is macOS case sensitive?

Not by default. A Mac disk is case insensitive and case preserving, so it stores the name exactly as you typed it while treating Report.pdf and report.pdf as the same file. Disk Utility offers a case sensitive APFS format as an option.

What does case preserving mean?

That the capitals you typed are kept and shown. It is a separate promise from case sensitivity. Preserving is about display, insensitivity is about comparison, with a Mac disk doing both at once.

Can I have two files with the same name in different cases?

Not on a default Mac volume. readme.md and README.md are one name there, so unpacking an archive containing both means one overwrites the other, nearly always without a warning.

Should I format my Mac as case sensitive?

Not the startup disk. Steam names a path it requires on a case insensitive file system and refuses otherwise. Unreal Engine has the same restriction. Installers of all kinds check for it. Add a separate case sensitive volume instead.

Why does Git not see my file rename on a Mac?

Because Git detects the file system when the repository is created and sets itself to ignore case. A rename that only changes capitals is not a change it can see, so the old name stays in the repository while your Mac displays the new one.

Why does my site work locally but not after deploying?

Because the server runs Linux, which is case sensitive. A link to images/Logo.png resolves on your Mac when the file is logo.png, since those are one name there. The server asks for exactly what was written and finds nothing.

Sources

Every behaviour stated above traces back to one of these pages. Last verified on 5 September 2026.

  1. Case sensitivity, options and implications, on case insensitive but case preserving behaviour and the detection command macOS and Unix
  2. Steam on a case sensitive file system, on the error naming the path Steam requires GitHub Gist
  3. For APFS, any reason not to use case sensitivity, on Steam and Unreal Engine failing MacRumors
  4. APFS is case insensitive by default, on Git ignoring case and the separate volume alternative swild.dev