JSON-Validator und -Formatierer
Validiere, formatiere und minifiziere JSON in deinem Browser mit genauen Fehlerpositionen.
JSON-Validator und -Formatierer wird geladen… Wenn nichts passiert, aktiviere JavaScript.
JSON (JavaScript Object Notation) ist ein leichtgewichtiges, für Menschen lesbares Datenaustauschformat, das auf einer Teilmenge der JavaScript-Syntax beruht. Es wurde Anfang der 2000er von Douglas Crockford als einfachere Alternative zu XML für den Datenaustausch zwischen Web-Clients und -Servern populär gemacht. Standardisiert 2006 als RFC 4627 und später als ECMA-404 und RFC 8259, ist JSON zur universellen Sprache von Web-APIs, Konfigurationsdateien und Datenspeicherung geworden. Seine sechs Werttypen (Zeichenkette, Zahl, Boolean, null, Array und Objekt) lassen sich sauber auf die Datenstrukturen praktisch jeder Programmiersprache abbilden.
Beispiele
{"name":"Ada","age":36}
Valid · object with 2 keys
{'name': 'Ada'}
Invalid · property names must use double quotes
JSON ist strenger als ein JavaScript-Objektliteral: keine einfachen Anführungszeichen, keine nachgestellten Kommata.
Häufig gestellte Fragen
Wird mein JSON an einen Server gesendet?
Welche genauen Regeln machen ein JSON gültig?
Was ist der Unterschied zwischen Formatieren und Minifizieren von JSON?
Wie unterscheidet sich JSON von der JavaScript-Objektliteral-Syntax?
Welche JSON-Größe kann ich validieren und formatieren?
Unterstützt der Validator JSON5 oder JSONC (JSON mit Kommentaren)?
Kann ich damit JSON innerhalb einer Zeichenkette formatieren (escaptes JSON)?
Ist JSON dasselbe wie BSON oder MessagePack?
Warum zeigt die Fehlermeldung nur den ersten Fehler?
Was ist ein häufiger Fehler, der JSON ungültig macht?
Über JSON-Validator und -Formatierer
JSON ist in der modernen Entwicklung unausweichlich. REST-APIs liefern JSON-Antworten. Konfigurationsdateien für Werkzeuge wie ESLint, TypeScript und npm nutzen JSON. NoSQL-Datenbanken wie MongoDB speichern Dokumente als BSON (binäres JSON). Die Ereignis-Nutzlasten von Serverless-Funktionen sind JSON-Objekte. Entwickler müssen routinemäßig JSON aus API-Antworten, Datenbankexporten, Logdateien, Webhook-Nutzlasten und Konfigurationsvorlagen prüfen, formatieren oder validieren. Ein einziges falsch platziertes Komma oder eine nicht geschlossene Klammer macht das gesamte Dokument ungültig, und rohes, minifiziertes JSON aus einer Produktions-API ist ohne Formatierung kaum lesbar.
Dieser JSON-Validator und -Formatierer analysiert deine Eingabe lokal im Browser mit der nativen Funktion JSON.parse, demselben Parser, den jede JavaScript-Laufzeit verwendet. Er hebt die genaue Zeile und Spalte jedes Syntaxfehlers hervor, damit du Probleme sofort finden und beheben kannst. Sobald das JSON gültig ist, gibt das Tool es mit konfigurierbarer Einrückung gut lesbar aus oder minifiziert es, indem es alle unnötigen Leerzeichen entfernt, um die Nutzlast zu verkleinern. Da alles in deinem Browser läuft, werden deine JSON-Daten, die API-Schlüssel, Benutzerdatensätze oder vertrauliche Geschäftsdaten enthalten können, nie an einen Server gesendet.
Häufige JSON-Fehler sind nachgestellte Kommata nach dem letzten Element eines Arrays oder Objekts (in JavaScript gültig, in JSON jedoch verboten), Zeichenketten in einfachen Anführungszeichen (JSON verlangt doppelte) und Kommentare (JSON hat keine Kommentarsyntax, anders als JSONC oder JSON5). Zahlen mit führenden Nullen (wie 007) sind ebenfalls ungültig. Wenn du mit einem Format arbeitest, das JSON um diese Funktionen erweitert, brauchst du stattdessen einen JSONC- oder JSON5-Parser; das Standard-JSON.parse lehnt sie ab.
Wie JSON das Web eroberte
JSON wurde von Douglas Crockford geschaffen und popularisiert, der 2001 die Domain json.org registrierte und begann, sich für JSON als leichtgewichtige Alternative zu XML für den AJAX-Datenaustausch einzusetzen. Crockfords zentrale Einsicht war, dass die Objekt- und Array-Literalsyntax von JavaScript bereits ein gültiges Datenformat war; sie musste nur dokumentiert, auf sichere Typen beschränkt und beworben werden. Er behauptete bekanntlich, JSON eher „entdeckt“ als erfunden zu haben, und merkte an, dass die Syntax bereits in JavaScript selbst angelegt war.
Trotz seiner Einfachheit war JSONs Weg zur Standardisierung überraschend umstritten. Crockford veröffentlichte es zunächst unter einer Lizenz mit dem Satz „Die Software soll für das Gute genutzt werden, nicht für das Böse“, was dazu führte, dass einige Open-Source-Organisationen es als unfrei einstuften. Als die ECMA JSON 2013 als ECMA-404 formalisierte und die IETF 2017 den RFC 8259 veröffentlichte, verwendeten sie eine saubere Lizenz, doch Crockford behielt die Klausel „das Gute, nicht das Böse“ in der ursprünglichen json.org-Spezifikation bei und schuf so eine beständige (und etwas humorvolle) Lizenz-Fußnote in der Geschichte der Web-Standards.
Heute ist JSON wohl das am weitesten verbreitete geparste Datenformat überhaupt. Jede große Programmiersprache liefert einen JSON-Parser in ihrer Standardbibliothek mit. REST-APIs, GraphQL-Antworten, NoSQL-Datenbanken, Konfigurationsdateien, Log-Aggregationssysteme und Serverless-Event-Busse nutzen JSON als ihr natives Format. Die Ironie ist, dass JSON, das einfacher als XML sein sollte, selbst so allgegenwärtig geworden ist, dass um es herum ganze Ökosysteme JSON-naher Formate (JSON5, JSONC, NDJSON, JSON Schema, JSON Pointer, JSON Patch) gewachsen sind, um seine Grenzen zu überwinden.