Skip to main content
Developer Tools

Der JSON-Leitfaden für Entwickler: Alles Wichtige für 2026

Die Spezifikation, die uneinigen Dialekte, die Zahlen, die still kaputtgehen, und der Sicherheitsrat, der auf die falsche Rekursion zeigt. Mit Cluster-Karte.

Von 7 min read
Titelkarte des Artikels. Ein großes Paar bernsteinfarbener geschweifter Klammern, mit der Zeile: one format, three dialects

JSON ist seit zwanzig Jahren das voreingestellte Austauschformat, und das meiste, was damit schiefgeht, ist nicht das Format. Es sind die Ränder: in welchem Dialekt eine Datei vorliegt, was mit einer 64-Bit-ID passiert, und welches Stück Code bei einem böswilligen Dokument tatsächlich umfällt.

Dies ist die Karte. Jeder Abschnitt verweist auf den Artikel, der tiefer geht.

Eine Karte der JSON-Artikel auf dieser Seite: dieser Leitfaden in der Mitte, dazu fünf vertiefende Artikel zu Dialekten, tsconfig-Kommentaren, Fehlersuche, Base64 und JWT-Prüfung
Fünf Artikel, fünf Fragen. Diese Seite ist das Verzeichnis.

Was JSON ist

Eine Teilmenge der JavaScript-Objektliteral-Syntax, definiert in RFC 8259, mit einer Grammatik, die auf eine Karteikarte passt1: Objekte mit Schlüsseln in doppelten Anführungszeichen, Arrays, Strings in doppelten Anführungszeichen, Dezimalzahlen sowie true, false und null.

Keine Kommentare. Keine nachgestellten Kommas. Kein Datumstyp. Kein Binärtyp. Diese Sparsamkeit ist der Grund, warum jede Sprache einen schnellen, einheitlichen Parser hat, und zugleich der Grund, warum Konfigurationsdateien, APIs und Binärdaten alle Umwege brauchen.

Die Dialekte, und eine Korrektur

Drei Formate teilen sich die Endung .json:

  • JSON, die strikte Grammatik aus RFC 8259.
  • JSONC, JSON mit Kommentaren, verwendet für VS Codes eigene Konfiguration und für tsconfig.json.
  • JSON5, eine deutlich grössere Erweiterung mit eigener veröffentlichter Spezifikation: Keys ohne Anführungszeichen, einfache Anführungszeichen, Hexadezimalzahlen, NaN, nachgestellte Kommas.

Eine frühere Fassung dieses Leitfadens sagte, JSONC habe "keine nachgestellten Kommas". Das ist die verbreitete Zusammenfassung, und sie ist falsch. Microsofts eigene Doku sagt, dass der Modus JSON with Comments nachgestellte Kommas akzeptiert und dabei eine Warnung zeigt2, und TypeScript liest eine tsconfig.json mit solchen Kommas ohne Diagnose. Die Bibliothek jsonc-parser, ebenfalls von Microsoft, lehnt sie ab, solange man nicht allowTrailingComma übergibt.

"Ist das gültiges JSONC" hat also keine Antwort, ohne den Parser und seine Optionen zu benennen, und genau das ist der Unterschied zu den anderen beiden: JSON hat einen RFC, JSON5 hat eine Spezifikation, und JSONC hat Voreinstellungen. JSON vs JSON5 vs JSONC arbeitet durch, was jeder Parser wirklich akzeptiert, und der Artikel warum tsconfig.json Kommentare verträgt behandelt den konkreten Fall, der die meisten überhaupt suchen lässt. Diesen gibt es bislang nur auf Englisch.

Wenn Sie eine Datei haben und nicht wissen, welches der drei sie ist, fügen Sie sie in den JSON-Dialekt-Detektor ein: Er benennt den Dialekt, zeigt auf jede Konstruktion, die striktes JSON ablehnen würde, und wandelt das Dokument in einfaches JSON um.

Die Regel, die das alles übersteht: einfaches JSON für alles, was eine Dienstgrenze überquert. JSONC dort, wo ein bestimmtes Werkzeug es nativ unterstützt. JSON5 nur, wenn Sie sich bewusst gegen Portabilität und für Bequemlichkeit entschieden haben, und das im Dateinamen sagen.

Die alltäglichen Handgriffe

Formatieren und prüfen. Unser JSON-Formatter parst und formatiert in der Seite. Bei ungültiger Eingabe zeigt er die Meldung der Engine selbst, und die trägt bei manchen Fehlern eine Zeichenposition und bei anderen nur einen zitierten Ausschnitt des Payloads. Diese Asymmetrie überrascht viele und wird in Fehlerhaftes JSON debuggen durchgearbeitet.

In eine Tabelle bringen. JSON zu CSV flacht ein Array von Objekten ab, verschachtelte Schlüssel in Punktnotation.

In ein Konfigurationsformat bringen. JSON zu YAML für Kubernetes, Actions und Compose-Dateien. TOML zu JSON , um pyproject.toml oder Cargo.toml aus JavaScript-Werkzeugen zu lesen.

Binärdaten, und die Tokens darauf

JSON-Strings sind Unicode-Text, rohe Bytes passen also nicht hinein. Der Standardumweg ist Base64:

{ "filename": "avatar.png", "content": "iVBORw0KGgoAAAANSUhEUgAA..." }

Kodiert, nicht verschlüsselt. Wer das JSON liest, liest die Bytes. Base64 erklärt behandelt die Varianten, auch die URL-sichere Form ohne Padding, die JWTs verwenden.

Und genau das ist ein JWT: drei Base64URL-Segmente, das mittlere ein JSON-Objekt mit Claims. Unser JWT-Decoder zeigt Ihnen diesen Payload, ohne die Signatur zu prüfen, was ihn zu einem Debugging-Werkzeug macht und ausdrücklich nicht zu einem Sicherheitswerkzeug. Die Fallstricke der Prüfung, allen voran die Algorithmus-Verwechslung, stehen in JWT-Authentifizierungsfehler.

Zahlen, wo die stillen Fehler wohnen

Die Spezifikation erlaubt beliebige Dezimalzahlen. Die meisten Parser speichern jede davon als IEEE-754-Double3, und daraus folgen drei Dinge.

Ganzzahlen sind oberhalb von 2^53 nicht mehr exakt, also etwa 9 Billiarden. Eine 64-Bit-ID darüber ändert beim Hin und Zurück still ihren Wert, weshalb die Lösung lautet, Bezeichner als Zeichenketten zu serialisieren und nie als Zahlen. Unser JSON-Formatter markiert Ganzzahlen in diesem Bereich, wenn er sie sieht, eine Kleinigkeit, die echte Zeit gespart hat.

Dezimalzahlen sind Näherungen. 0.1 + 0.2 serialisiert als 0.30000000000000004. Geld gehört in Zeichenketten oder in ganzzahlige Kleinsteinheiten.

NaN und Infinity sind kein JSON, auch wenn manche Bibliotheken sie trotzdem ausgeben. Pythons json-Modul tut das standardmässig, in beide Richtungen, weshalb solche Payloads innerhalb von Python sauber laufen und überall sonst scheitern.

Schicken Sie Ihre grösste ID und Ihre genaueste Dezimalzahl einmal durch den echten Stack. Das dauert eine Minute und ist die einzige Art, es zu wissen.

Schemata

JSON Schema beschreibt die Form eines JSON-Dokuments in JSON und ist die Grundlage der meisten API-Validierung. OpenAPI verpackt es für HTTP-APIs und liefert generierte Clients dazu.

Intern bringen Zod oder Pydantic dieselbe Validierung mit weniger Zeremonie. Austauschformate sind sie nicht, sobald also ein externer Verbraucher Ihre Form kennen muss, sind Sie wieder bei JSON Schema.

Performance, gemessen statt vermutet

JSON.parse lief auf Node 24 mit etwa 434 MB/s auf einem 800 KB grossen Payload typischer API-Datensätze. Schnell genug, dass es selten Ihr Engpass ist, und langsam genug, um bei hohem Durchsatz aufzufallen.

Bei der Kompression ist die überlieferte Weisheit am wenigsten hilfreich. Derselbe Payload wurde mit gzip 12-mal und mit brotli 42-mal kleiner, weil fünftausend Datensätze immer wieder dieselben Schlüsselnamen wiederholen. Ein Payload aus überwiegend einmaligem Fliesstext komprimiert weit schlechter. Eine feste Zahl zu nennen ist der Fehler; die Antwort hängt vollständig davon ab, wie wiederholungsreich Ihre Daten sind, und Ihre eigenen zu messen kostet einen Befehl.

Standard-Parser laden ausserdem das ganze Dokument in den Speicher, wirklich grosse Dateien brauchen also einen Streaming-Parser: stream-json in Node, ijson in Python.

Wenn JSON doch zum Engpass wird, der Reihe nach: HTTP-Kompression einschalten, Felder nicht mehr serialisieren, die niemand liest, und erst dann ein Binärformat für internen Verkehr erwägen.

Sicherheit, auf die richtige Rekursion gerichtet

JSON mit einem Serialisierer bauen, nie durch Zusammenkleben von Zeichenketten. Das ist die ganze JSON-Injection.

Tiefe Verschachtelung ist kein Parser-Problem, jedenfalls nicht hier.

Verschachtelungstiefe gemessen auf Node 24. JSON.parse nahm eine Million Ebenen verschachtelter Objekte fehlerfrei an, während ein naiver rekursiver Lauf über dem Ergebnis bei zehntausend den Aufrufstapel überschritt
Die überall wiederholte Massnahme zielt auf die Komponente, die überlebt hat.

Der Standardrat lautet, die Rekursionstiefe des Parsers zu begrenzen. Auf Node 24 gemessen schluckte JSON.parse eine Million Ebenen verschachtelter Objekte ohne Murren, weil V8s Parser iterativ arbeitet und Tiefe Heap statt Stack kostet. Die dreizeilige rekursive Funktion, die das Ergebnis danach durchläuft, warf bei zehntausend einen RangeError: Maximum call stack size exceeded.

Die Angriffsfläche ist also nicht der Parser. Es ist jeder Validierer, Bereiniger, Schwärzer und Formatierer, den Sie als rekursive Funktion geschrieben haben. Begrenzen Sie die Grösse des Anfrage-Bodys und laufen Sie nicht rekursiv über Formen, die Sie nicht gewählt haben.

Prototype Pollution ist JavaScript-spezifisch und enger als ihr Ruf: JSON.parse legt __proto__ als gewöhnliche eigene Eigenschaft an, das Parsen allein ist also unbedenklich. Riskant wird es, wenn Sie dieses Objekt in ein anderes mischen oder als Nachschlagetabelle verwenden. Für fremde Schlüssel lieber Map.

Betrieb

Ein JSON-Objekt pro Zeile loggen, also ndjson, damit jeder Aggregator und jq es versteht:

{"ts":"2026-08-19T09:00:00Z","level":"info","msg":"user signed in","user_id":42}

Vor dem Diffen normalisieren. Erst Schlüssel sortieren und Leerraum entfernen, sonst ist der Diff nur Formatierungsrauschen.

Keine grosse gemeinsame Konfiguration in einer JSON-Datei. Jede gleichzeitige Änderung kollidiert, und JSON lässt sich schlecht zusammenführen. Aufteilen, oder ein Format nehmen, mit dem Text-Merge-Werkzeuge zurechtkommen.

Die Haltung

JSON ist langweilig, und das ist die beste Eigenschaft, die ein Austauschformat haben kann. Die Arbeit besteht nicht darin, die Grammatik zu verstehen, sondern die Ränder zu kennen: in welchem Dialekt die Datei vorliegt, was Ihr Parser mit einer grossen Ganzzahl macht, und welche Ihrer eigenen Funktionen die rekursive ist.

Alles hier Verlinkte läuft in Ihrem Browser und lädt nichts hoch, was zählt, wenn der Payload, den Sie untersuchen, eine Produktionsantwort ist. Die Cluster-Artikel gehen bei jedem Teil in die Tiefe; diese Seite sagt Ihnen, welchen Sie brauchen.

Quellen

Jede Zahl in diesem Artikel lässt sich auf eine Quelle unten zurückführen. Behauptungen ohne Beleg wurden gestrichen, nicht abgeschwächt.

  1. PrimärquelleIETF

    Die vollständige JSON-Grammatik, die weder eine Produktion für Kommentare noch nachgestellte Kommas, einen Datumstyp oder einen Binärtyp kennt.

  2. PrimärquelleMicrosoft

    Dass der Modus JSON with Comments für VS Codes eigene Konfigurationsdateien verwendet wird und nachgestellte Kommas akzeptiert, dabei aber eine Warnung anzeigt.

  3. PrimärquelleEcma International

    Dass der Number-Typ das 64-Bit-Doppelgenauigkeitsformat nach IEEE 754 ist, weshalb die Ganzzahlgenauigkeit in den meisten JSON-Parsern oberhalb von 2 hoch 53 endet.

Themen

  • JSON
  • Developers
  • Guide
  • JWT
  • Base64
  • Debugging

In diesem Artikel erwähnte Tools

Neue Tools per E-Mail

Neue Tools und gelegentlich ein ausführlicher Artikel, etwa einmal im Monat. Kein Spam, deine Adresse bekommt niemand, Abmeldung mit einem Klick.

Ähnliche Artikel

Titelkarte des Artikels. Ein Paar große geschweifte Klammern mit einem bernsteinfarbenen Warnzeichen dazwischen, mit der Zeile: the parser knows where it broke
Developer Tools

Fehlerhaftes JSON debuggen: ein Feldhandbuch

Die Parse-Meldung ist besser als ihr Ruf. Wie man liest, was V8 heute sagt, die fünf Fehlerarten hinter kaputten Payloads, und die zwei Meldungen ohne Position.

Titelkarte des Artikels. Drei graue Quadrate und ein Pfeil führen zu vier schmaleren bernsteinfarbenen Balken, mit der Zeile: 3 bytes become 4 characters
Developer Tools

Base64 erklärt: Was es ist, warum es existiert und wann nicht

Was Base64 mit Ihren Bytes macht, die drei Varianten, die fast alle Decode-Fehler verursachen, und die Stellen, an denen es sich lohnt.

Die Wörter JSON, JSONC und JSON5 übereinander in großer weißer Schrift auf dunklem Grund, eingerahmt von zwei überdimensionierten geschweiften Klammern
Developer Tools

JSON vs JSON5 vs JSONC: Was welcher Parser wirklich akzeptiert

Drei Formate, eine Dateiendung und keine Einigkeit darüber, was gültig ist. Gemessen an den echten Parsern, darunter zwei, die sich widersprechen und dieselbe Bibliothek sind.