JSON kennt nur sechs Datentypen und eine strenge Syntax: doppelte Anführungszeichen, keine Kommentare, kein abschließendes Komma. Wie JSON aufgebaut ist und warum diese Strenge es zum universellen Austauschformat macht.

JSON begegnet dir überall: in Konfigurationsdateien, in API-Antworten, in Datenbanken. Fast jede Anwendung, die Daten über das Netz austauscht, spricht JSON. Der Grund liegt in einer ungewöhnlichen Kombination: Das Format ist für Menschen lesbar und trotzdem so streng definiert, dass jeder Parser es exakt gleich interpretiert. In diesem Ratgeber lernst du, wie JSON aufgebaut ist, welche sechs Datentypen es kennt und warum die strengen Regeln kein Hindernis, sondern der eigentliche Vorteil sind.

Woher JSON kommt

JSON steht für JavaScript Object Notation. Der Name verrät die Herkunft: Das Format leitet sich von der Art ab, wie du in JavaScript Objekte notierst. Douglas Crockford hat JSON Anfang der 2000er Jahre populär gemacht und formalisiert. Wichtig ist, dass er JSON nicht erfunden, sondern eine bereits vorhandene Schreibweise herausgelöst und als eigenständiges Datenformat beschrieben hat.

Heute ist JSON gleich zweifach standardisiert. Die ECMA-404 beschreibt die reine Syntax, also welche Zeichenfolgen überhaupt gültiges JSON sind. Der RFC 8259 der IETF ergänzt Details für den praktischen Datenaustausch, etwa die Vorgabe, UTF-8 als Zeichenkodierung zu verwenden. Beide Dokumente sind bewusst kurz gehalten. Genau diese Knappheit ist ein Qualitätsmerkmal: Es gibt wenig Spielraum für Interpretationen.

Ein zentraler Punkt, der oft überrascht: JSON ist zwar aus JavaScript entstanden, aber vollständig sprachunabhängig. Ob Python, Java, Go, PHP oder Rust, jede ernstzunehmende Programmiersprache kann JSON lesen und schreiben. Das Format gehört keiner Sprache mehr.

Die zwei Grundbausteine

JSON kennt genau zwei Strukturen, aus denen sich alles zusammensetzt: das Objekt und das Array.

Ein Objekt ist eine ungeordnete Sammlung von Schlüssel-Wert-Paaren. Es beginnt mit einer geschweiften Klammer { und endet mit }. Jeder Schlüssel ist ein String, gefolgt von einem Doppelpunkt und dem zugehörigen Wert. Mehrere Paare trennst du mit Kommas.

{
  "name": "Ada Lovelace",
  "geboren": 1815,
  "mathematikerin": true
}

Ein Array ist eine geordnete Liste von Werten. Es beginnt mit einer eckigen Klammer [ und endet mit ]. Die Werte trennst du ebenfalls mit Kommas.

["Rot", "Grün", "Blau"]

Das Besondere: Werte können selbst wieder Objekte oder Arrays sein. So kannst du beliebig tief verschachteln und komplexe Datenstrukturen abbilden.

{
  "buch": "Grundlagen der Analysis",
  "autoren": ["E. Landau"],
  "verlag": {
    "name": "Chelsea",
    "jahr": 1929
  }
}

Die sechs Werttypen

Ein Wert in JSON ist immer genau einer von sechs Typen. Diese kleine, feste Menge ist ein wesentlicher Grund für die Zuverlässigkeit des Formats.

Typ	Beschreibung	Beispiel
string	Text in doppelten Anführungszeichen	`"Hallo Welt"`
number	Ganzzahl oder Dezimalzahl, auch mit Exponent	`42`, `-3.14`, `2.5e3`
boolean	Wahrheitswert	`true`, `false`
null	ausdrücklich kein Wert	`null`
object	Sammlung von Schlüssel-Wert-Paaren	`{ "a": 1 }`
array	geordnete Liste von Werten	`[1, 2, 3]`

Ein paar Details lohnen sich. Ein string muss immer in doppelten Anführungszeichen stehen. Sonderzeichen maskierst du mit einem Backslash, etwa \" für ein Anführungszeichen im Text oder \n für einen Zeilenumbruch. Eine number kennt keinen Unterschied zwischen Ganzzahl und Kommazahl, es ist schlicht eine Zahl. Als Dezimaltrennzeichen dient immer der Punkt, nie das Komma. Führende Nullen wie 007 sind nicht erlaubt.

Genauso wichtig ist, was JSON nicht kennt. Es gibt keinen eigenen Typ für Datum und Uhrzeit. Ein Zeitstempel wird als String transportiert, üblicherweise im ISO-8601-Format:

{
  "erstellt": "2026-07-03T14:30:00Z"
}

Ebenso fehlen die aus JavaScript bekannten Werte undefined und NaN. Wenn du “kein Wert” ausdrücken willst, nimmst du null. Und es gibt keinen Typ für Kommentare, dazu gleich mehr. Diese bewusste Sparsamkeit sorgt dafür, dass jeder Parser dieselben sechs Bausteine erwartet und keiner rätseln muss, wie ein exotischer Typ zu behandeln ist.

Die strengen Regeln

JSON ist unnachgiebig, und das mit Absicht. Wer aus YAML oder aus lockerem JavaScript-Code kommt, stolpert anfangs über dieselben Punkte. Hier sind die wichtigsten Regeln.

Schlüssel stehen immer in doppelten Anführungszeichen. Anders als in JavaScript, wo du Objektschlüssel oft ohne Anführungszeichen schreibst, verlangt JSON sie zwingend.

{
  "gueltig": true
}

Falsch wäre { gueltig: true } ohne Anführungszeichen um den Schlüssel.

Nur doppelte Anführungszeichen sind erlaubt. Einfache Anführungszeichen, wie sie in vielen Programmiersprachen für Strings üblich sind, akzeptiert JSON nicht.

{
  "sprache": "Deutsch"
}

Ein 'Deutsch' mit einfachen Anführungszeichen ist ungültig.

Kein abschließendes Komma. Das letzte Element in einem Objekt oder Array darf kein Komma hinter sich haben. Dieses sogenannte trailing comma ist eine der häufigsten Fehlerquellen überhaupt.

{
  "eins": 1,
  "zwei": 2
}

Ein Komma nach "zwei": 2 würde den Parser abbrechen lassen.

Keine Kommentare. JSON erlaubt weder // noch /* */. Wenn eine Datei Kommentare enthält, ist sie kein gültiges JSON, auch wenn manche Werkzeuge kulant darüber hinwegsehen. Willst du deine Konfiguration kommentieren, ist das oft ein Grund, YAML in Betracht zu ziehen. Warum YAML hier flexibler ist, liest du im Vergleich JSON und YAML im Vergleich.

Whitespace, Pretty-Print und Minify

Leerzeichen, Tabs und Zeilenumbrüche zwischen den Elementen sind für JSON bedeutungslos. Der Parser ignoriert sie. Das gibt dir Freiheit bei der Formatierung, ändert aber nichts an den Daten selbst.

In der Praxis unterscheidest du zwei Formen. Die Pretty-Print-Variante ist eingerückt und für Menschen gut lesbar:

{
  "stadt": "Hamburg",
  "plz": "20095",
  "bezirke": ["Altstadt", "HafenCity"]
}

Die minifizierte Variante wirft allen überflüssigen Whitespace weg. Sie ist kompakter und spart bei der Übertragung Bytes, ist aber schwerer zu lesen:

{"stadt":"Hamburg","plz":"20095","bezirke":["Altstadt","HafenCity"]}

Beide enthalten exakt dieselben Daten. Für die Übertragung über eine API nutzt man meist die minifizierte Form, für Konfigurationsdateien und zum Debuggen die eingerückte.

Typische Fehlerquellen

Aus der Strenge folgen ein paar Fehler, die dir garantiert begegnen werden:

Trailing comma: ein Komma hinter dem letzten Element.
Einfache statt doppelte Anführungszeichen bei Strings oder Schlüsseln.
Vergessene Anführungszeichen um einen Schlüssel.
Kommentare, die aus einer anderen Datei kopiert wurden.
Komma statt Punkt als Dezimaltrennzeichen, also 3,14 statt 3.14.
Nicht maskierte Sonderzeichen in Strings, etwa ein nacktes Anführungszeichen mitten im Text.

Wenn du beim Umwandeln solcher Daten auf Nummer sicher gehen willst, kannst du auf jsonyaml.de dein JSON nach YAML umwandeln und dabei die Einrückung frei wählen. Die Umwandlung läuft komplett in deinem Browser, ohne Upload auf einen Server.

Warum die Strenge ein Vorteil ist

Auf den ersten Blick wirken die vielen Regeln wie eine Schikane. Tatsächlich sind sie der Kern dessen, was JSON so nützlich macht.

Weil die Grammatik so eng gefasst ist, gibt es zu jeder gültigen JSON-Zeichenkette nur eine einzige richtige Interpretation. Es gibt keine Sonderfälle, keine impliziten Umwandlungen, keine mehrdeutige Einrückung. Ein Parser in Python liefert dasselbe Ergebnis wie einer in Java oder JavaScript. Diese Eindeutigkeit ist beim Datenaustausch zwischen unterschiedlichen Systemen Gold wert.

Die Einfachheit hat noch einen zweiten Effekt: JSON-Parser sind klein, schnell und in praktisch jeder Programmiersprache Teil der Standardbibliothek. Du musst keine Abhängigkeit installieren, um JSON zu lesen. Diese universelle Unterstützung hat JSON zum De-facto-Standard für Web-APIs gemacht.

Der Preis dafür ist die fehlende Bequemlichkeit: keine Kommentare, kein Datumstyp, kein nachlässiges Komma. Für Konfigurationsdateien, die viel von Hand bearbeitet werden, empfinden viele diese Strenge als lästig. Genau hier setzt YAML an, das für Menschen freundlicher ist. Wie YAML aufgebaut ist, erklärt der Ratgeber zu den YAML-Syntax-Grundlagen. Wann sich der Wechsel lohnt und wann du besser bei JSON bleibst, beantwortet Wann du YAML statt JSON verwenden solltest.

Für den reinen Maschinen-zu-Maschinen-Austausch aber ist die Strenge kein Nachteil, sondern die Grundlage der Verlässlichkeit. Du weißt bei jedem gültigen JSON-Dokument genau, was du bekommst, und das über Sprach- und Systemgrenzen hinweg.

Hast du einen Fehler entdeckt oder einen Quellen-Hinweis für uns? Schreib gern an info@akara-solutions.de.

JSON verstehen: Aufbau, Datentypen und strenge Regeln