JSON vs JSON5 vs JSONC: Was welcher Parser wirklich akzeptiert

Eine Konfigurationsdatei, die Ihr Editor klaglos darstellt, kann JSON.parse trotzdem um die Ohren fliegen. Beide haben recht. Sie lesen verschiedene Sprachen, die sich eine Dateiendung teilen.

Von diesen Sprachen sind drei verbreitet, und nur eine davon hat eine Spezifikation, die alle gleich umsetzen.

Was striktes JSON wirklich erlaubt

JSON, wie es RFC 8259 definiert, ist eine kleine Teilmenge von JavaScript-Objektliteralen, und die Grammatik passt tatsächlich auf eine Serviette¹: Objekte mit Keys in doppelten Anführungszeichen, Arrays, Strings in doppelten Anführungszeichen, Dezimalzahlen und die drei Literale true, false und null.

Alles, worüber man stolpert, folgt daraus, dass das die ganze Sprache ist.

Keine Kommentare. Weder // noch /* */. Crockfords angegebener Grund für die Streichung ist, dass Leute begonnen hatten, sie als Parser-Direktiven zu verwenden, was die Interoperabilität zerstört hätte⁵. Ob man das überzeugend findet oder nicht: die Grammatik kennt keine Produktion für Kommentare, ein Parser, der einen akzeptiert, parst also kein JSON.

Keine nachgestellten Kommas. [1, 2, 3,] ist ungültig, und das ist die mit Abstand häufigste Art, wie eine handbearbeitete Datei kaputtgeht.

Keys sind Strings in Anführungszeichen. {foo: 1} ist JavaScript. {"foo": 1} ist JSON.

Kein Hex, kein NaN, kein Infinity. Hier lohnt Genauigkeit, weil es oft verkehrt herum erzählt wird: JavaScript erzeugt diese Werte ebenfalls nicht. JSON.stringify(NaN) liefert den String null, und JSON.stringify(Infinity) genauso. Die Werte überstehen einen Roundtrip von vornherein nicht.

Doppelte Keys sind undefiniertes Verhalten. Der RFC sagt, Namen SOLLTEN eindeutig sein, und dass das Verhalten unvorhersehbar ist, wenn sie es nicht sind¹. Die meisten Parser behalten den letzten. Manche brechen ab.

Die Strenge ist der ganze Wert. Wenn alle Implementierungen sich über die Grammatik einig sind, liest sich eine in Python geschriebene Datei in Go identisch.

JSONC hat keine Spezifikation, nur Standardwerte

JSONC ist das, was Microsoft "JSON with Comments" nennt. VS Code öffnet settings.json, tasks.json, launch.json und alles andere in .vscode/ in diesem Modus³.

Die übliche Zusammenfassung lautet, JSONC sei striktes JSON plus zwei Kommentarsyntaxen und sonst nichts. Diese Zusammenfassung ist falsch, und man kann ihr beim Falschsein zusehen.

Microsofts eigene Dokumentation sagt, der Modus akzeptiere auch nachgestellte Kommas, sie seien aber unerwünscht und der Editor zeige eine Warnung³. TypeScript 5.9.3 liest eine tsconfig.json mit Kommentar und nachgestellten Kommas und liefert eine geparste Konfiguration ganz ohne Diagnosen zurück. Das Paket jsonc-parser, ebenfalls von Microsoft, lehnt dieselbe Datei mit vier Fehlern ab, solange man nicht allowTrailingComma übergibt.

"Ist das gültiges JSONC" hat also keine Antwort, ohne den Parser und seine Optionen zu nennen. Das ist der praktische Unterschied zu den beiden anderen: JSON hat einen RFC, JSON5 hat eine Spezifikation, und JSONC hat einen Standardwert.

JSON5 ist aufgeschrieben

JSON5 ist eine deutlich größere Erweiterung, und anders als JSONC ist sie aufgeschrieben². Hinzu kommen:

• Kommentare mit // und /* */
• Nachgestellte Kommas in Objekten und Arrays
• Keys ohne Anführungszeichen, sofern der Key ein gültiger Bezeichner ist
• Strings in einfachen Anführungszeichen
• Mehrzeilige Strings über escapte Zeilenumbrüche
• Hexadezimalzahlen
• Führende und nachgestellte Dezimalpunkte, also .5 und 5.
• Infinity, -Infinity und NaN
• Ein explizites führendes + bei Zahlen

Erklärtes Ziel ist eine Obermenge von JSON, gebaut aus Produktionen von ECMAScript 5.1 und darauf ausgelegt, von Menschen leichter von Hand geschrieben und gepflegt zu werden². Praktisch heißt das: gültiges JSON5 ist gültiges JavaScript, das Sie in eine .js-Datei einfügen könnten.

Die Referenztabelle

"Kommt darauf an" ist in der JSONC-Spalte keine Ausflucht. Es ist die Antwort.

Konstrukt	JSON	JSONC	JSON5
Kommentare // und /* */	Nein	Ja	Ja
Nachgestellte Kommas	Nein	Je nach Parser	Ja
Keys ohne Anführungszeichen	Nein	Nein	Ja
Einfache Anführungszeichen	Nein	Nein	Ja
Hex-Zahlen	Nein	Nein	Ja
NaN und Infinity	Nein	Nein	Ja
Führender oder nachgestellter Punkt	Nein	Nein	Ja
Von JSON.parse akzeptiert	Ja	Nein	Nein
Hat eine schriftliche Spezifikation	Ja	Nein	Ja

Alles darüber wurde am 19.08.2026 durch JSON.parse unter Node 24.18, jsonc-parser 3.3.1 und json5 laufen gelassen, statt aus einer anderen Tabelle übernommen.

Die Endung sagt Ihnen nichts

Der Rat, den alle geben, auch die frühere Fassung dieses Artikels, lautet, JSON5-Dateien .json5 zu nennen, damit niemand überrascht wird. Der Rat ist gut. Babel befolgt ihn nicht: babel.config.json und .babelrc.json werden als JSON5 geparst⁴, Endung hin oder her.

Zur konkreten Frage, warum tsconfig.json Kommentare duldet und package.json nicht, gibt es einen eigenen Artikel, bislang nur auf Englisch.

Eines auswählen

Striktes JSON, wenn irgendetwas außer Ihnen die Datei liest. API-Antworten, Exporte, Logs, Schema-Dateien. Jede Sprache hat einen schnellen strikten Parser, und niemand muss fragen, welchen Dialekt Sie meinten.

JSONC, wenn ein Werkzeug, das Sie ohnehin verwenden, es nativ unterstützt, praktisch also VS-Code-Konfiguration und tsconfig.json. Sie bekommen Kommentare dort, wo Kommentare sich wirklich lohnen: in einer Datei, die sich selten ändert und beim Ändern erklärt werden muss.

JSON5, wenn Sie Portabilität bewusst gegen Ergonomie getauscht haben, und sagen Sie es im Dateinamen. Interne Build-Konfiguration, Fixtures mit viel wiederholter Struktur.

Der Problemfall ist eine Datei namens config.json, die still JSON5-Features verwendet, denn die nächste Person greift zu JSON.parse und bekommt einen Stacktrace ohne jeden Hinweis darin.

Eine Datei lesen, deren Dialekt Sie nicht kennen

Fügen Sie sie in den JSON-Dialekt-Detektor ein: er benennt den Dialekt, zeigt auf die genaue Zeile jedes Konstrukts, das striktes JSON ablehnen würde, und wandelt das Dokument in einfaches JSON um. Unser JSON-Formatter arbeitet nach der strikten Grammatik, wenn er also bei einer Datei einen Fehler meldet, mit der Ihr Editor zufrieden ist, ist diese Datei kein JSON.

Im Code sollten Sie Kommentare nicht per regulärem Ausdruck entfernen. Nehmen Sie einen Parser, der den Dialekt versteht, und geben Sie ihm die Optionen, die Sie tatsächlich wollen:

import { parse } from 'jsonc-parser';

const errors = [];
const value = parse(source, errors, { allowTrailingComma: true });
if (errors.length) throw new Error(`fehlerhafte Konfiguration: ${errors.length} Probleme`);
// `value` sind jetzt einfache Daten und lassen sich mit JSON.stringify neu serialisieren

Für den Wechsel zwischen Serialisierungsformaten decken JSON zu YAML , JSON zu CSV und TOML zu JSON die üblichen Richtungen ab.

Wenn ein Parse-Vorgang scheitert, ist die nützliche erste Frage nicht, ob Ihr JSON falsch ist. Sie lautet, in welcher der drei Sprachen die Datei geschrieben ist und welche der Parser erwartet hat.