JSON Formatter & Validator

Warum JSON überall ist

JSON (JavaScript Object Notation) wurde 2001 von Douglas Crockford als leichtgewichtiges Subset von JavaScript-Objektliteralen spezifiziert. 25 Jahre später ist es das Standardformat für die überwältigende Mehrheit aller öffentlichen APIs — REST, GraphQL, WebSocket-Payloads, Konfigurationsdateien, Log-Zeilen. Die Einfachheit ist das Feature: nur sechs Werttypen (String, Zahl, Boolean, null, Objekt, Array), kein Schema-Zwang, keine binäre Framing-Schicht.

Neuere Formate wie Protocol Buffers, MessagePack und CBOR existieren aus guten Gründen (kleiner, typisiert, schneller zu parsen). Aber JSONs Lesbarkeit für Menschen macht es weiterhin zur Lingua franca für alles, was ein Entwickler im Texteditor öffnen möchte.

Die strengen Regeln, die beißen

Die JSON-Spezifikation (RFC 8259) ist strenger als die JavaScript-Syntax, von der sie abstammt. Drei Regeln stolpern Entwickler regelmäßig: (1) Schlüssel MÜSSEN doppelt-gequotete Strings sein — `{name: "x"}` ist ungültig, `{"name": "x"}` ist erforderlich. (2) Abschließende Kommas sind nicht erlaubt: `[1, 2, 3,]` parst in JavaScript, aber nicht in JSON. (3) Kommentare sind überhaupt nicht erlaubt — weder `//` noch `/* */`.

Die meisten Parser lehnen auch NaN, Infinity und -Infinity ab (nicht in der Spec), unescape Steuerzeichen in Strings und verlangen UTF-8-Encoding. Manche „lockeren" Parser (JSON5, HJSON, JSONC) akzeptieren diese — aber wenn du JSON5 an einen strikten Konsumenten lieferst, schlägt es fehl.

Formatieren vs. Minimieren: Wann was?

Formatiertes JSON (mit Einrückung und Zeilenumbrüchen) ist für Menschen — Code-Reviews, Debugging, Konfigurationsdateien im Git. Minimiertes JSON (ohne Whitespace) ist für die Leitung — jedes Byte kostet Latenz und Bandbreite, und eine typische Config-Datei wird durch Minimierung 30–60 % kleiner.

Faustregel: formatiert speichern (Dateien, Logs, DevTools), minimiert übertragen (API-Antworten, Message Queues). Die meisten Produktions-HTTP-Server gzippen JSON ohnehin transparent, sodass sich die Einsparungen kombinieren: 1 MB formatiertes JSON gzippt zu ~80 KB, dieselben Daten minimiert zu ~70 KB. Kleiner Unterschied, aber kostenlos.

Häufige Parse-Fehler und ihre Lösung

„Unexpected token X at position N" — zähle bis Position N, um das problematische Zeichen zu finden. Fast immer eines davon: ein unge­quoteter Schlüssel, ein einfaches Anführungszeichen, ein abschließendes Komma oder ein nicht-escapter Backslash in einem String.

„Unexpected end of JSON input" — die Datei wurde während des Parsens abgeschnitten. Häufig bei Datei-Uploads, die ein Limit treffen, oder bei abgebrochenen Netzwerkantworten ohne Fehlerprüfung.

„Duplicate key" — JSON erlaubt doppelte Schlüssel laut Spec, aber die meisten Parser warnen oder behalten still nur den letzten. Schreibe kein JSON mit doppelten Schlüsseln; das Verhalten ist implementierungsabhängig.

Über Formatierung hinaus: Validierung und Schema

Validierung hier bedeutet „ist die Syntax legales JSON" — ein syntaktischer Check. Für semantische Validierung („hat dieses Objekt die Felder, die meine API erwartet?") verwende JSON Schema (RFC-Draft) mit einem Validator wie Ajv (JavaScript) oder jsonschema (Python). JSON Schema erlaubt es, Typen, Pflichtfelder, Wertebereiche, Regex-Patterns für Strings und Referenzen zwischen Schemas zu deklarieren.

In Produktions-APIs validiere am Rand. Eine fehlerhafte Payload sollte schnell mit 400 und einer klaren Fehlermeldung scheitern — nicht still den nachgelagerten Zustand korrumpieren. JSON Schema generiert solche Fehler automatisch und ist sprachübergreifend portabel.