Was ist JSON? Syntaxregeln und häufige Fehler beheben

JSON (JavaScript Object Notation) ist ein Textformat, das strukturierte Daten als Schlüssel-Wert-Paare und geordnete Listen darstellt, aufgebaut aus nur sechs Werttypen. Es ist das Format, das fast jede Web-API zum Senden und Empfangen von Daten verwendet, und es taucht ebenso in Konfigurationsdateien, Logzeilen und NoSQL-Datenbanken auf. Anders als ein JavaScript-Objektliteral, dem es äußerlich ähnelt, folgt JSON einem kleinen, strengen Regelwerk, und ein einziger Verstoß macht das gesamte Dokument unlesbar für den Parser.

Was JSON eigentlich ist

Jedes JSON-Dokument besteht aus genau sechs Werttypen:

• String, ausschließlich in doppelten Anführungszeichen, etwa "hallo"
• Zahl, etwa 42 oder 3.14
• Boolean, entweder true oder false
• null
• Objekt, eine ungeordnete Menge von Schlüssel-Wert-Paaren in {}
• Array, eine geordnete Liste von Werten in []

Das ist das komplette Typsystem. Es gibt keinen Datumstyp, kein undefined, keinen Funktionstyp, sonst nichts. Objekte und Arrays können beliebig tief ineinander verschachtelt werden, aber jeder Wert auf jeder Ebene muss einer dieser sechs Kategorien entsprechen.

Die dazugehörigen Syntaxregeln sind genauso festgelegt:

• Objektschlüssel müssen doppelt zitierte Strings sein. `{"name":"Ada"}` ist gültig, `{name:"Ada"}` ist es nicht.
• Kein Komma nach dem letzten Element. Die letzte Eigenschaft eines Objekts und das letzte Element eines Arrays dürfen kein nachgestelltes Komma haben.
• Keine Kommentare, weder // noch /* */.
• Strings und Schlüssel verwenden ausschließlich doppelte Anführungszeichen. Einfache Anführungszeichen sind zwar in JavaScript gültig, in JSON aber nicht.
• Schlüssel dürfen nie unquotiert bleiben, egal wie einfach der Name ist.
• NaN, Infinity und undefined sind keine gültigen JSON-Werte, obwohl alle drei in JavaScript funktionieren.
• Funktionen lassen sich in JSON nicht abbilden. Verhalten kann nicht serialisiert werden, nur Daten.

Verstößt ein Dokument gegen auch nur eine dieser Regeln, bricht der Parser ab und meldet einen Fehler, statt zu erraten, was gemeint war.

JSON im Vergleich zu einem JavaScript-Objektliteral

Die geschweiften und eckigen Klammern von JSON stammen aus der JavaScript-Objekt- und Array-Syntax, und genau deshalb werden beide so oft verwechselt. Auf den ersten Blick sehen sie fast identisch aus, aber ein JavaScript-Objektliteral ist an jeder Stelle nachsichtiger, an der JSON streng ist:

Merkmal	JSON	JavaScript-Objektliteral
Schlüssel müssen in Anführungszeichen stehen	Ja, nur doppelte	Nein, optional
Komma nach letztem Element erlaubt	Nein	Ja
Kommentare erlaubt	Nein	Ja
Strings in einfachen Anführungszeichen	Nein	Ja
Funktionen als Werte	Nein	Ja
undefined als Wert	Nein	Ja

An dieser Stelle geht viel Debugging-Zeit verloren. Wer ein Objektliteral direkt aus einer JavaScript-Datei kopiert, unquotierte Schlüssel, Komma am Ende und alles, und es an eine Stelle einfügt, die JSON erwartet, bekommt etwas, das als JavaScript anstandslos läuft, aber an JSON.parse scheitert. JSON ist keine Teilmenge von JavaScript-Syntax, die man beiläufig hinschreiben kann, sondern ein eigenständiges, strengeres Format, das sich mit JavaScript nur die Satzzeichen teilt.

Praxisbeispiel: eine echte API-Antwort minifizieren und formatieren

Nimm ein typisches Benutzerobjekt, wie es eine API zurückgeben könnte:

{
  "id": 1,
  "name": "Ada Lovelace",
  "email": "[email protected]",
  "roles": [
    "admin",
    "user"
  ],
  "active": true,
  "meta": null
}

Diese formatierte Version mit 2-Leerzeichen-Einrückung ist 145 Zeichen lang. Dieselben Daten minifiziert, also ohne jedes Leerzeichen und ohne Zeilenumbrüche, sehen so aus:

{"id":1,"name":"Ada Lovelace","email":"[email protected]","roles":["admin","user"],"active":true,"meta":null}

Das sind 107 Zeichen, etwa 35 % weniger, und der gesamte Unterschied besteht ausschließlich aus Whitespace. Kein einziger Wert und kein Schlüssel hat sich geändert, die Daten sind identisch.

Deshalb schicken APIs JSON minifiziert über die Leitung: Im großen Maßstab summieren sich diese eingesparten 35 % über Millionen von Requests zu spürbarer Bandbreiten- und Latenzersparnis, und kein Client-Code braucht die Einrückung, um den Wert korrekt zu parsen. Für einen Menschen ist derselbe minifizierte String aber kaum lesbar. Wer eine Antwort debuggt und die Verschachtelung, die Schlüsselnamen und die Grenzen eines Arrays sehen muss, formatiert sie zurück auf die eingerückte Version. Gleiche Daten, zwei verschiedene Zwecke: einer für Maschinen, einer für dich.

Formatiere dein eigenes JSON

Füge unten minifiziertes oder unordentliches JSON ein, um es sauber eingerückt zu sehen, oder nutze das Tool umgekehrt, um ein formatiertes Dokument zu minifizieren, bevor du es an eine Stelle schickst, wo die Größe zählt.

JSON Formatter, Beautifier & Validator

Kostenlos, ohne Anmeldung, auf jedem Gerät.

Vollständiges Tool öffnen

Häufige Fehler und Grenzfälle

Komma nach dem letzten Element. Bei `{"id":1,"name":"Ada",}` meldet V8 (die Engine hinter Chrome und Node.js):

Expected double-quoted property name in JSON at position 21 (line 1 column 22)

Nach dem Komma hinter "Ada" folgt nichts mehr, und JSON kennt kein optionales, nachgestelltes Trennzeichen. Firefox’ SpiderMonkey-Engine formuliert ihre Fehlermeldungen anders, aber in jeder JSON-konformen Engine schlägt der Parse-Vorgang auf dieselbe Weise fehl.

Unquotierte Schlüssel. `{id:1}` scheitert mit:

Expected property name or '}' in JSON at position 1 (line 1 column 2)

Der Parser erwartet direkt nach { einen doppelt zitierten String und findet stattdessen einen nackten Bezeichner.

Schlüssel in einfachen Anführungszeichen. `{'a':1}` trifft dieselbe Fehlerklasse:

Expected property name or '}' in JSON at position 1 (line 1 column 2)

Einfache Anführungszeichen sind in JSON kein gültiger Weg, einen String zu öffnen, also behandelt der Parser 'a' genauso wie einen unquotierten Schlüssel: als keinen gültigen Property-Namen.

NaN und undefined als Werte. `{"a":NaN}` erzeugt:

Unexpected token 'N', "{"a":NaN}" is not valid JSON

Und `{"a":undefined}` erzeugt:

Unexpected token 'u', "{"a":undefined}" is not valid JSON

Beides ist in einem JavaScript-Objektliteral erlaubt, hat aber keine Entsprechung in JSON. Kann ein Wert in deiner Anwendung NaN oder undefined sein, musst du ihn vor dem Serialisieren in null oder einen String umwandeln.

Doppelte Schlüssel überschreiben sich stillschweigend. `{"a":1,"a":2}` ist syntaktisch gültiges JSON, ganz ohne Fehler, und wird zu `{"a":2}` geparst. Die meisten Parser, auch der von JavaScript, behalten nur das letzte Vorkommen eines wiederholten Schlüssels und verwerfen das frühere, ohne Warnung. Das ist eine subtile Quelle echter Bugs: Ein Build-Tool, das Konfigurationsfragmente zusammenfügt, oder eine von Hand bearbeitete Datei, in der jemand einen Block versehentlich zweimal einfügt, kann denselben Schlüssel doppelt enthalten, und weil kein Fehler auftritt, fällt es niemandem auf, bis irgendwo weiter unten im Ablauf der falsche Wert auftaucht.

Häufig gestellte Fragen

Was ist JSON? JSON (JavaScript Object Notation) ist ein Textformat für strukturierte Daten, aufgebaut aus sechs Werttypen: Strings, Zahlen, Booleans, null, Objekten und Arrays. Es ist das gängigste Format für API-Anfragen und -Antworten und wird außerdem in Konfigurationsdateien und vielen Datenbanken verwendet.

Ist JSON dasselbe wie ein JavaScript-Objekt? Nein. JSON sieht aus wie ein JavaScript-Objektliteral, ist aber strenger: Schlüssel müssen doppelt zitiert werden, ein Komma nach dem letzten Element ist nicht erlaubt, Kommentare sind nicht erlaubt, und Werte wie undefined oder eine Funktion lassen sich gar nicht darstellen. Ein JavaScript-Objektliteral erlaubt all das, JSON keines davon.

Warum bricht ein überzähliges Komma mein JSON? Weil die Grammatik von JSON keine Regel für ein zusätzliches Komma nach dem letzten Element eines Objekts oder Arrays kennt. Ein Parser, der `{"id":1,"name":"Ada",}` liest, erwartet nach dem Komma einen weiteren Property-Namen und findet stattdessen die schließende Klammer, genau das meldet der Fehler “Expected double-quoted property name in JSON”.

Unterstützt JSON Kommentare? Nein. Für // oder /* */ gibt es in der JSON-Spezifikation keine Syntax. Wer eine JSON-Datei für Menschen kommentieren möchte, weicht meist auf eine separate Dokumentationsdatei, einen zusätzlichen "_comment"-Schlüssel, der wie normale Daten behandelt wird, oder ein Format aus, das Kommentare unterstützt, etwa JSON5 oder YAML.

Was ist der Unterschied zwischen Formatieren und Minifizieren? Formatieren (auch Beautifying oder Prettifying genannt) fügt Einrückung und Zeilenumbrüche hinzu, damit ein Mensch die Struktur auf einen Blick erfasst. Minifizieren entfernt genau das, um den kürzestmöglichen String zu erzeugen. Beide Formen stellen exakt dieselben Daten dar, der Unterschied liegt rein in der Darstellung, und es ist üblich, je nach Zweck zwischen beiden hin- und herzukonvertieren, je nachdem, ob das JSON von einem Menschen gelesen oder über ein Netzwerk verschickt wird.

Werden meine Daten an einen Server gesendet, wenn ich einen Online-Formatter benutze? Beim JSON Formatter von pluri.tools nicht. Formatieren, Minifizieren und Validieren laufen komplett über JSON.parse und JSON.stringify in der JavaScript-Engine deines Browsers. Es gibt keinen Fetch- oder Netzwerkaufruf, das eingefügte JSON verlässt dein Gerät nicht.