macOS auto-generates screenshot filenames with a timestamp, like:

Screenshot 2026-04-07 at 3.57.20 pm.png

That looks normal, but the space between 3.57.20 and pm isn’t a regular space. It’s U+202F, a Narrow No-Break Space (NNBSP). macOS uses this character in its locale-aware time formatting to keep the time and the AM/PM indicator together.

You can see this if you look at the filename in a terminal. Bash can’t render the character directly in a path, so it shows the raw UTF-8 bytes in octal escape form:

'Screenshot 2026-04-07 at 3.57.20'$'\342\200\257''pm.png'

The $'\342\200\257' is the three-byte UTF-8 encoding of U+202F.

This can cause problems. If you type a filename with a regular space where the NNBSP should be, the path won’t match. Scripts that split on spaces won’t split at this character. Tools that assume ASCII filenames may choke on it entirely.

A few situations where this bites:

  • Tab-completing the filename works, but copy-pasting from a file listing and editing the path by hand may silently replace the NNBSP with a regular space.
  • grep or find patterns using a literal space won’t match the NNBSP position.
  • Some web servers or upload tools may mangle the character, producing a different filename on the other end.
  • LLM-based tools like Claude can trip on it. I’ve seen Claude run ls to list files, see a screenshot filename in the output, then try to read the file using the path as displayed — with a regular space where the NNBSP should be. The file isn’t found, and it’s not obvious why.

The character is harmless in most day-to-day use. But when it shows up unexpectedly in a script or tool that doesn’t handle Unicode well, it can be a confusing bug to track down. Now you know what that $'\342\200\257' is.

I don’t think there’s much we can do about this. It’s inconvenient, and it’s just the way it is.