JSON Errors / All languages
JSON fails to parse: BOM / invisible character at position 0How to Fix: JSON fails to parse: BOM / invisible character at position 0
A byte-order mark (BOM) is an invisible character (U+FEFF, bytes EF BB BF in UTF-8) that some editors and Windows tools write at the start of files. The JSON RFC says implementations must not add a BOM and may reject input that has one - and most strict parsers do reject it, each with its own confusing message.
The defining symptom: the file looks perfectly valid, every online validator you paste it into says it is valid (copy-paste usually drops the BOM), yet your program fails at position 0 / line 1 column 1. The evidence only appears when you inspect raw bytes.
Common causes
1. File saved as "UTF-8 with BOM"
Windows Notepad (older versions), Excel CSV/JSON exports, and some IDE settings write the BOM by default. PowerShell 5 redirection (>) writes UTF-16 with BOM.
2. String concatenation carrying a BOM mid-document
Concatenating file contents can embed a BOM in the middle of the JSON, where it is invalid in every parser regardless of leniency at the start.
3. Other invisible characters that behave the same
Non-breaking spaces (U+00A0) from word processors and zero-width spaces (U+200B) from web copy-paste also break parsing while remaining invisible.
How to fix it
# shell - EF BB BF at the start means UTF-8 BOM
head -c 3 file.json | xxd
# JavaScript
console.log(raw.charCodeAt(0) === 0xfeff); // true -> BOM
# Python
print(repr(open("file.json", "rb").read(3))) # b''// JavaScript
const clean = raw.replace(/^/, "");
# Python - encoding that consumes a BOM if present
with open("file.json", encoding="utf-8-sig") as f:
data = json.load(f)
# shell - remove in place
sed -i '1s/^//' file.jsonVS Code: status bar -> "UTF-8 with BOM" -> "Save with Encoding" -> UTF-8
git: add a .gitattributes rule and a CI check, e.g.
grep -rlI $'' --include='*.json' . && exit 1Frequently asked questions
Why do online validators say my file is valid when my code rejects it?
Selecting and copying text usually does not copy the BOM - so the validator receives clean text while your program reads the raw file bytes. Always test with the actual file (or check bytes with xxd) when a "valid" document refuses to parse.
Which parsers tolerate a BOM?
Some are lenient: C#'s System.Text.Json skips a UTF-8 BOM in bytes, and Gson tolerates it in lenient mode. JavaScript's JSON.parse, Python's json.loads (on a str containing ), Go, and PHP reject it. Never rely on leniency - strip at the boundary.
Should I ever write a BOM into JSON I produce?
No. RFC 8259 section 8.1: "Implementations MUST NOT add a byte order mark to the beginning of a networked-transmitted JSON text." UTF-8 needs no byte-order signal; the BOM is pure compatibility residue that breaks strict consumers.
Last updated:
Related JSON errors
You might also need
Free and in-browser, like everything on JSON Console. Browse all tools →