JSON formatieren und validieren, ohne es zu zerstören

JSON wirkt einfach, bis ein fehlendes Komma das Deployment kippt. Die meisten JSON-Fehler sind nicht exotisch: Es sind Kommas am Ende, einfache Anführungszeichen, Kommentare oder eine Klammer, die nicht passt. Dieser Leitfaden zeigt, was gültiges JSON wirklich erlaubt, welche Fehler am häufigsten auftreten und wie du einen Payload zuverlässig formatierst und prüfst.

Was gültiges JSON erlaubt

JSON hat eine sehr kleine Grammatik:

• Ein Wert ist ein Objekt, Array, String, eine Zahl, true, false oder null.
• Objekt-Keys müssen Strings in doppelten Anführungszeichen sein.
• Strings nutzen doppelte Anführungszeichen; einfache sind nicht gültig.
• Arrays und Objekte dürfen kein Komma am Ende haben.
• Kommentare sind nicht Teil der JSON-Spezifikation.
• Zahlen dürfen nicht NaN, Infinity oder hexadezimal sein.

Das ist im Wesentlichen alles. Die Strenge ist der Punkt: Jeder JSON-Parser in jeder Sprache kann sich auf dieselbe Eingabe einigen.

Die fünf häufigsten Fehler

1. Kommas am Ende

{
  "name": "Ada",
  "age": 36,
}

In JavaScript und in JSON5 ist das gültig, in JSON nicht. Entferne das Komma nach der letzten Property.

2. Einfache Anführungszeichen

{ 'name': 'Ada' }

JSON akzeptiert nur doppelte Anführungszeichen. Das passiert meist, wenn du von Hand aus Python oder JavaScript kopierst.

3. Keys ohne Anführungszeichen

{ name: "Ada" }

Objekt-Keys müssen Strings in doppelten Anführungszeichen sein. Auch das ist eine JavaScript-Gewohnheit, die JSON nicht teilt.

4. Kommentare

{
  // the user's name
  "name": "Ada"
}

JSON kennt keine Kommentare. Wenn du Kommentare in einer Config brauchst, nutze JSONC oder YAML – aber schicke keine Kommentare an eine JSON-API.

5. Klammern, die nicht passen

Eine fehlende } oder ] erzeugt den Fehler oft am Dateiende statt an der eigentlichen Stelle. Wenn du das Dokument formatierst, siehst du die fehlende Ebene viel schneller.

Warum Formatieren hilft

Minifiziertes JSON ist effizient für Maschinen, aber mühsam für Menschen. Ein formatiertes Dokument:

• zeigt die Struktur auf einen Blick;
• macht Diffs im Code-Review lesbar;
• hilft dir, eine fehlende Klammer oder ein fehlendes Komma zu finden;
• gibt dir eine stabile Form, um zwei Payloads zu vergleichen.

Wenn du eine API-Antwort debuggst, füge sie vor dem Lesen in einen Formatter ein. Wenn du zwei Versionen vergleichst, formatiere beide zuerst und diff sie dann. Formatieren entfernt Whitespace-Rauschen und macht die echte Änderung sichtbar.

Pretty Print oder minifizieren?

Pretty Printing fügt Einrückung und Zeilenumbrüche für Lesbarkeit hinzu. Minifizieren entfernt allen optionalen Whitespace für den Transport. Es sind dieselben Daten; entscheide nach Publikum:

• Pretty Print für Logs, Doku, Test-Fixtures und Debugging.
• Minifiziertes JSON für Request-Bodies und Antworten, bei denen Bytes zählen.

Ein Formatter sollte dir den Wechsel zwischen 2 Leerzeichen, 4 Leerzeichen, Tabs und minifizierter Ausgabe erlauben, ohne die Werte zu verändern.

Fehler mit Zeilennummern finden

Die nützlichste Fehlermeldung ist nicht „invalid JSON“, sondern „unexpected token in Zeile 4, Spalte 3“. Moderne Parser liefern meist eine Position, das Format der Meldung unterscheidet sich aber je nach Runtime.

Ein Formatter im Browser kann das Dokument parsen, Zeile und Spalte melden und die Ausgabe leer lassen, bis das JSON gültig ist. Diese Rückmeldung ist viel schneller, als zu raten, welche Klammer fehlt.

Der JSON Formatter macht genau das: Payload einfügen, Fehlerposition sehen und dann formatieren oder minifizieren, sobald es parst. Alles läuft lokal, du kannst ihn also bedenkenlos mit Produktions-Payloads nutzen.

JSON ist kein JavaScript-Objekt

Ein JavaScript-Object-Literal darf Funktionen, undefined, Keys mit einfachen Anführungszeichen und Kommentare enthalten. JSON nicht. Die Verwechslung ist verbreitet, weil die Syntax ähnlich aussieht – aber JSON ist ein Datenformat, keine Sprache.

Wenn du JSON in einen JavaScript-Wert umwandeln willst, übernimmt JSON.parse das. Wenn du ein JavaScript-Objekt in JSON umwandeln willst, macht JSON.stringify Folgendes:

• undefined und Funktionen fallen weg;
• Daten werden zu Strings;
• zirkuläre Referenzen werfen einen Fehler;
• NaN und Infinity werden zu null.

Wer diese Regeln kennt, verhindert eine ganze Klasse von „warum ist dieses Feld verschwunden?“-Bugs.

Von JSON in andere Formate

Sobald ein Payload gültig ist, brauchst du ihn oft in einer anderen Form:

• JSON zu CSV macht aus einem Array von Objekten eine Tabelle.
• YAML zu JSON bewegt Konfiguration zwischen beiden Formaten.
• Diff Checker vergleicht einen alten und einen neuen Payload, nachdem beide formatiert sind.

Eine praktische Checkliste

1. Füge den Payload in einen Formatter ein und behebe zuerst Syntaxfehler.
2. Formatiere beide Versionen, bevor du sie vergleichst.
3. Minifiziere erst, wenn du die Daten wirklich sendest.
4. Halte Kommentare aus JSON heraus; nutze YAML oder JSONC für Configs, die sie brauchen.
5. Nutze JSON nicht für Secrets, die du nicht in ein Log schreiben würdest.

JSON ist absichtlich streng. Wenn du die paar Regeln kennst, werden die meisten Parser-Fehler innerhalb von Sekunden offensichtlich.