If a filename ends with a space, do Windows and Mac treat it as the same file?

Question

Weirdo · Accepted Answer

No. Windows' shell and Win32 APIs do not allow a name to end in a space or period — they strip those characters on save. APFS stores the UTF-8 name as given. The same-looking string is not the same file on both systems.

Microsoft's naming rules are blunt: do not end a file or directory name with a space or a period. The underlying file system may support such names; the Windows shell and user interface do not. A separate support note spells out what happens when you try anyway: a name that begins or ends with ASCII space (0x20) is saved without those characters; a trailing period is stripped too. The Object Manager does this on create. Rename report.txt to "report.txt " in Explorer and the disk usually still holds report.txt. NTFS can store the space — Win32 just parses it away first. The same naming document says a \?\ prefix disables that parsing and sends the string straight to the file system.

Apple's APFS FAQ says the file system accepts valid UTF-8 names and preserves case and normalization on disk. ASCII space is valid UTF-8; it is not listed as forbidden. On a Mac, "report.txt " can really end with a space. That is not "the same file" as Windows' report.txt — it is the mismatch. If such a name later exists on NTFS, Microsoft's troubleshooting note has the awkward case: a folder that contains both AFile.txt and "AFile.txt " (trailing space). Open the second with ordinary Win32 calls and you get the first. Explorer may still list it; delete and rename often miss, because the trailing space is stripped before the path reaches the file system. The documented \?\ syntax is how you address the name that actually has the space.

If a filename ends with a space, do Windows and Mac treat it as the same file?

Windows strips the trailing space first

macOS keeps the space