Does a BOM break JSON parsing
Bottom line: A UTF-8 BOM is three invisible bytes, so JSON.parse fails on the first character and reports line 1 column 1, which makes the file look empty or truncated.
Bottom line: check the first three bytes for EF BB BF and re-save as UTF-8 without BOM; on the server, strip a leading U+FEFF before parsing any uploaded or third-party file instead of debugging the failure later.
Yes — and it produces the most confusing of all parse errors, because the file looks perfectly fine.
What you see
SyntaxError: Unexpected token in JSON at position 0
Unexpected character '\uFEFF'
That character in the message is invisible. Position 0 means the very first byte.
cat shows nothing unusual. hexdump -C file.json | head -1 does:
00000000 ef bb bf 7b 0a 20 20 22 61 22 3a 20 31 0a 7d 0a |...{ "a": 1.}.|
7b is {. The three bytes before it are the BOM.
Where BOMs come from
The byte order mark existed for UTF-16, where byte order genuinely varied. UTF-8 has a single byte order, so the BOM is pure overhead — yet Notepad on Windows, some Excel exports, and a few older IDEs still write it by default.
RFC 8259 is unambiguous: JSON exchanged between systems must be UTF-8, and implementations must not add a BOM. Parsers may ignore a leading BOM but are not required to. Browsers and Node choose not to.
Three ways to get rid of it
Save without BOM. In VS Code, click the encoding in the status bar and pick "Save with Encoding → UTF-8", not "UTF-8 with BOM".
Strip it from the shell.
sed -i '1s/^\xEF\xBB\xBF//' data.json
Strip it on read. This is the durable fix for anything accepting uploaded or third-party files:
const text = require('node:fs').readFileSync('data.json', 'utf8').replace(/^\uFEFF/, '');
JSON.parse(text);
In Python, open(path, encoding='utf-8-sig') handles it automatically.
Two lookalike problems
- Zero-width space (U+200B) — picked up when copying JSON from a web page; identical symptom, different codepoint.
- Full-width quotes — a Chinese IME turns
"key"into“key”, which looks nearly identical but fails asUnexpected token “.
All three are invisible-character bugs. The diagnostic is always the same: dump the first bytes in hex rather than staring at the text.
FAQ
How can I tell whether a file starts with a BOM?
cat shows nothing, so run hexdump -C file.json | head -1. If the output begins with ef bb bf, the file has a BOM; 7b (the {) should come first in a clean UTF-8 file.
Why does the error always point at line 1, column 1?
The BOM sits before everything else, so the first character the parser reads is U+FEFF. The failure therefore lands at the start of the file, which makes the file look empty.
Should I strip the BOM before parsing?
Yes. When a server reads config or parses uploaded files, strip a leading U+FEFF first — replace(/^\uFEFF/, '') in Node, encoding='utf-8-sig' in Python — which is much cheaper than diagnosing it later.