Häufige JSON-Fehler und wie man sie behebt

Aktualisiert: 28. September 2026

JSON ist das Format, in dem viele APIs, Konfigurationsdateien und Web-Apps Daten austauschen, und seine Grammatik passt auf eine einzige Seite. Gerade deshalb verzeiht es nichts: Ein Text ist entweder gültiges JSON oder nicht, und ein einziges überzähliges Komma genügt, damit ein Parser das Ganze ablehnt. Die meisten Fehler gehen auf dieselben wenigen Gewohnheiten zurück, viele davon aus JavaScript oder anderen Sprachen übernommen. Dieser Ratgeber zeigt die Regeln, die Fehler, die am häufigsten gegen sie verstoßen, wie man die Fehlermeldung liest und einige Fälle, die gültiges JSON sind, aber trotzdem Probleme verursachen.

Welche Regeln JSON tatsächlich hat

Die aktuellen Definitionen sind RFC 8259, veröffentlicht im Dezember 2017, und ECMA-404. Beide beschreiben dieselbe Syntax:

Strings, einschließlich aller Eigenschaftsnamen, stehen in doppelten Anführungszeichen. Einfache Anführungszeichen sind nicht erlaubt.
Werte sind Strings, Zahlen, Objekte, Arrays oder eines von drei Literalen: true, false und null, immer kleingeschrieben.
Die Elemente in Objekten und Arrays werden durch Kommas getrennt, ohne Komma nach dem letzten.
Zahlen werden dezimal geschrieben, ohne führende Nullen, ohne Pluszeichen und ohne NaN oder Infinity.
Innerhalb eines Strings müssen das doppelte Anführungszeichen, der Backslash und Steuerzeichen wie ein Zeilenumbruch als Escape-Sequenz geschrieben werden.
Es gibt keine Syntax für Kommentare.

Zwischen den Tokens sind nur vier Leerraumzeichen erlaubt: Leerzeichen, Tabulator, Zeilenvorschub und Wagenrücklauf.

Die häufigsten Fehler

Jeder dieser Fälle wird von einem standardkonformen Parser abgelehnt. Die Lösung steht jeweils in der Beschreibung.

{"name": "Ana",}Nachgestelltes Komma: Das Komma nach dem letzten Element eines Objekts oder Arrays muss entfernt werden.
{'name': 'Ana'}Einfache Anführungszeichen: Für Eigenschaftsnamen und Strings sind doppelte Anführungszeichen zu verwenden.
{name: "Ana"}Eigenschaftsname ohne Anführungszeichen: Jeder Name muss ein String in doppelten Anführungszeichen sein.
{"a": 1 "b": 2}Fehlendes Komma zwischen zwei Elementen, oft nachdem Zeilen zusammenkopiert wurden.
{“name”: “Ana”}Typografische Anführungszeichen, die Textverarbeitungen und Chat-Apps automatisch einfügen: Sie müssen durch gerade Anführungszeichen " ersetzt werden.
{"note": 1 // total}Kommentare gehören nicht zu JSON: Man entfernt sie oder verschiebt die Notiz in eine Eigenschaft.
{"active": True}Großgeschriebene Literale: true, false und null werden kleingeschrieben.
{"value": undefined}undefined, NaN und Infinity gibt es in JavaScript, aber nicht in JSON: Stattdessen verwendet man null oder einen String.
{"code": 007}Führende Nullen sind in Zahlen nicht erlaubt: Man schreibt 7 oder, wenn die Nullen wichtig sind, "007" als String.
{"path": "C:\Users"}Ein einzelner Backslash leitet eine Escape-Sequenz ein, und \U ist keine. Schlimmer noch: C:\new würde akzeptiert und als C:, ein Zeilenumbruch und ew gelesen. Für einen wörtlichen Backslash schreibt man \\.
{"items": [1, 2}Eine Klammer, die nie oder mit dem falschen Zeichen geschlossen wird: Jede { braucht eine } und jede [ eine ].

JSON-Formatierer & Konverter

Die Fehlermeldung lesen

Ein Parser liest den Text von links nach rechts und bricht beim ersten Zeichen ab, das er nicht akzeptieren kann. Die Position in der Fehlermeldung ist also die Stelle, an der er aufgegeben hat – oft direkt hinter dem eigentlichen Fehler. Bei einem nachgestellten Komma beschwert sich der Parser über die schließende geschweifte Klammer, weil er nach einem Komma einen weiteren Eigenschaftsnamen erwartet. Fehlt eine Klammer, kann der Fehler ganz am Ende des Textes auftauchen, weit entfernt von der Stelle, an der die Klammer hätte stehen sollen.

Der Wortlaut unterscheidet sich je nach Browser und Sprache, und viele Meldungen nennen eine Position, wenn auch nicht alle – entweder als Zahl der Zeichen ab dem Anfang oder als Zeile und Spalte. Die JavaScript-Engine von Chrome meldet {"name":"Ana",} zum Beispiel so:

Expected double-quoted property name in JSON at position 14 (line 1 column 15)Ab 0 gezählt ist Position 14 die schließende geschweifte Klammer; das Komma, das den Fehler verursacht hat, steht ein Zeichen davor.

Ist die Position nicht offensichtlich, lohnt ein Blick auf das Zeichen direkt davor; außerdem sollte man prüfen, ob jede öffnende Klammer und jedes Anführungszeichen vor dieser Stelle ein Gegenstück hat. Ein Editor, der zusammengehörige Klammern hervorhebt, macht eine fehlende oft leicht erkennbar.

Gültiges JSON, das trotzdem Probleme macht

Große Zahlen. JSON selbst setzt keine Grenze, aber JavaScript und viele JSON-Parser in anderen Sprachen speichern Zahlen als 64-Bit-Gleitkommazahlen, die ganze Zahlen nur bis 9.007.199.254.740.991 garantiert exakt darstellen. In JavaScript macht JSON.parse aus 9007199254740993 ohne jede Warnung 9007199254740992. Große IDs sind als Strings sicherer.
Doppelte Eigenschaftsnamen. Laut RFC 8259 sollten Namen eindeutig sein, und Software, die Duplikate erhält, verhält sich unvorhersehbar. JavaScript behält den letzten Wert: {"a": 1, "a": 2} wird zu {"a": 2}.
Ein Byte Order Mark. Manche Editoren speichern UTF-8-Dateien mit einem unsichtbaren Zeichen U+FEFF am Anfang. RFC 8259 verbietet, es JSON hinzuzufügen, das über ein Netzwerk gesendet wird, und JSON.parse in JavaScript lehnt Text ab, der damit beginnt.
Ein primitiver Wert auf oberster Ebene. Die aktuellen Standards (ECMA-404 sowie RFC 7159 ab 2014) erlauben, dass ein JSON-Text ein beliebiger Wert ist, etwa "hello" oder 42, doch der ältere RFC 4627 aus dem Jahr 2006 verlangte ein Objekt oder ein Array, und manche ältere Parser tun das noch immer.

JSON ist nicht JavaScript

Die Syntax von JSON wurde von JavaScript-Objektliteralen übernommen, deshalb werden die beiden so leicht verwechselt. Ein JavaScript-Objektliteral akzeptiert einfache Anführungszeichen, Namen ohne Anführungszeichen, nachgestellte Kommas, Kommentare und Werte wie undefined; JSON akzeptiert nichts davon. Code, der in ein Skript eingefügt funktioniert, kann deshalb als JSON-Datei scheitern.

Manche Werkzeuge akzeptieren erweiterte Formate wie JSON5 oder „JSON mit Kommentaren“ für Konfigurationsdateien. Wo sie unterstützt werden, sind sie praktisch, aber sie sind kein JSON, und ein standardkonformer Parser – auch der nTools-Formatierer – lehnt sie ab.

Häufige Fragen

Kann JSON Kommentare enthalten?

Nein. Die Spezifikation kennt keine Syntax für Kommentare. Wer Notizen in den Daten braucht, legt sie in eine Eigenschaft wie "_comment" oder verwendet ein Format, das Kommentare erlaubt, sofern die Werkzeuge es unterstützen.

Warum funktioniert mein JSON in JavaScript, aber nicht in einem Validator?

Weil ein JavaScript-Objektliteral Dinge erlaubt, die JSON nicht erlaubt, etwa einfache Anführungszeichen, nachgestellte Kommas und Namen ohne Anführungszeichen. In Code eingefügt läuft es; als JSON gespeichert ist es ungültig.

Wie bleibt eine sehr große Zahl exakt?

Man sendet sie als String, zum Beispiel "9007199254740993", und wandelt sie auf der Empfängerseite in einen Typ um, der sie aufnehmen kann, etwa BigInt in JavaScript.

Sendet der nTools-Formatierer mein JSON irgendwohin?

Nein. Es wird im eigenen Browser geparst und formatiert, und wenn der Browser eine Position meldet, zeigt der Formatierer sie als Zeile und Spalte an.