Bricht ein BOM das JSON-Parsen
Fazit: Ein UTF-8-BOM sind drei unsichtbare Bytes, JSON.parse scheitert also am ersten Zeichen und meldet Zeile 1, Spalte 1, was die Datei leer oder abgeschnitten aussehen lässt.

Kurz gesagt: Prüfen Sie die ersten drei Bytes auf EF BB BF und speichern Sie als UTF-8 ohne BOM erneut; entfernen Sie auf dem Server ein führendes U+FEFF, bevor Sie eine hochgeladene oder Drittanbieter-Datei parsen, statt den Fehlschlag später zu debuggen.
Ja – und es erzeugt den verwirrendsten aller Parse-Fehler, weil die Datei vollkommen in Ordnung aussieht.
Was man sieht
SyntaxError: Unexpected token in JSON at position 0
Unexpected character '\uFEFF'
Das Zeichen in der Meldung ist unsichtbar. Position 0 bedeutet das allererste Byte.
cat zeigt nichts Ungewöhnliches. hexdump -C file.json | head -1 schon:
00000000 ef bb bf 7b 0a 20 20 22 61 22 3a 20 31 0a 7d 0a |...{ "a": 1.}.|
7b ist {. Die drei Bytes davor sind das BOM.
Woher BOMs kommen
Die Byte Order Mark gab es für UTF-16, wo die Byte-Reihenfolge tatsächlich variierte. UTF-8 hat eine einzige Byte-Reihenfolge, das BOM ist also reiner Overhead – dennoch schreiben Notepad unter Windows, manche Excel-Exporte und einige ältere IDEs es standardmäßig.
RFC 8259 ist eindeutig: Zwischen Systemen ausgetauschtes JSON muss UTF-8 sein, und Implementierungen dürfen kein BOM hinzufügen. Parser dürfen ein führendes BOM ignorieren, sind aber nicht verpflichtet. Browser und Node entscheiden sich dagegen.
Drei Wege, es loszuwerden
Ohne BOM speichern. Klicken Sie in VS Code auf die Kodierung in der Statusleiste und wählen Sie „Mit Kodierung speichern → UTF-8“, nicht „UTF-8 mit BOM“.
Aus der Shell enfernen.
sed -i '1s/^\xEF\xBB\xBF//' data.json
Beim Lesen entfernen. Das ist die dauerhafte Lösung für alles, was hochgeladene oder Drittanbieter-Dateien akzeptiert:
const text = require('node:fs').readFileSync('data.json', 'utf8').replace(/^\uFEFF/, '');
JSON.parse(text);
In Python erledigt open(path, encoding='utf-8-sig') das automatisch.
Zwei ähnlich aussehende Probleme
- Zero-Width-Leerzeichen (U+200B) – entsteht beim Kopieren von JSON aus einer Webseite; identisches Symptom, anderer Codepoint.
- Vollbreite Anführungszeichen – eine chinesische Eingabemethode macht
"key"zu“key”, was fast identisch aussieht, aber alsUnexpected token “scheitert.
Alle drei sind Unsichtbare-Zeichen-Bugs. Die Diagnose ist immer dieselbe: die ersten Bytes hexadezimal ausgeben, statt den Text anzustarren.
FAQ
Wie kann ich feststellen, ob eine Datei mit einem BOM beginnt?
cat zeigt nichts, führen Sie also hexdump -C file.json | head -1 aus. Beginnt die Ausgabe mit ef bb bf, hat die Datei ein BOM; 7b (das {) sollte in einer sauberen UTF-8-Datei zuerst kommen.
Warum zeigt der Fehler immer auf Zeile 1, Spalte 1?
Das BOM steht vor allem anderen, das erste Zeichen, das der Parser liest, ist also U+FEFF. Der Fehlschlag landet daher am Dateianfang, was die Datei leer aussehen lässt.
Sollte ich das BOM vor dem Parsen entfernen?
Ja. Liest ein Server Konfiguration oder parst hochgeladene Dateien, entfernen Sie zuerst ein führendes U+FEFF – replace(/^\uFEFF/, '') in Node, encoding='utf-8-sig' in Python –, was weit billiger ist, als es später zu diagnostizieren.