Zero-width and invisible
ZERO WIDTH NO-BREAK SPACE (U+FEFF)
The byte order mark. At the very start of a file it announces the encoding; anywhere else it is an invisible, non-breaking nothing that Unicode has deprecated for that use since 3.2.
- Codepoint
U+FEFF- Category
- Zero-width and invisible
- Removed by default
- Yes
- Governing option
- No option needed
- Can be load-bearing
- No
Where it comes from
Windows editors, Excel exports and anything that writes "UTF-8 with BOM". Concatenating several such files leaves a BOM in the middle of the result. Copying from a spreadsheet cell often carries one along.
Why it matters
A leading BOM breaks JSON parsers, YAML front matter, shell shebangs and CSV headers; a BOM in the middle is simply an invisible character that defeats exact-match comparison. It is also the reason a config file "looks fine" but will not load.
Before and after
The invisible first character is why `JSON.parse` refuses this string.
The character is shown as a labelled chip so you can see where it sits. In your text it draws nothing at all.
When it is legitimate
As the first character of a file, as an encoding signature — which is a property of the FILE, not of the text. Once the text is in a paste box, there is no legitimate BOM left.
How to remove it
The default pass removes it, wherever it sits. Ghostchars works on text, so it treats the leading BOM as text too.
Is it an AI watermark?
Not a watermark
No. A BOM is an encoding artefact produced by editors and export pipelines. It says something about the tool that saved the file and nothing about who wrote the words.
No connection to machine-generated text. It comes from software, from a keyboard, or from a person.
Questions
Why does my JSON fail to parse?
A leading BOM is a character before the opening brace. Most JSON parsers reject it as an unexpected token, and the error points at position 0 with nothing visible there.
Is it the same as a word joiner?
They behave the same way in the middle of text. Unicode deprecated U+FEFF for that use and made U+2060 WORD JOINER the correct character, leaving U+FEFF as the byte order mark only.
Do I ever need to keep it?
Only if a downstream tool insists on a BOM-marked file, and then you add it when writing the file — not by carrying it around inside the text.
Check your own text
Paste anything into the cleaner to see every hidden character it contains, with position, codepoint and what happens to each one. Nothing is uploaded.