JSON-Syntax-Validator

1. 1JSON einfügen oder hochladenFügen Sie Ihr JSON in den Editor ein oder ziehen Sie eine .json-, .jsonc-, .json5-, .ndjson-, .geojson- oder .webmanifest-Datei auf die Ablagefläche. Minifiziertes und formatiertes JSON funktionieren beide, und nichts wird irgendwohin hochgeladen.
2. 2Auf Validieren drückenJeder Syntaxfehler erscheint auf einmal mit Zeile, Spalte und Byte-Offset, und eine Markierung zeigt auf das genaue Zeichen. Gültiges JSON zeigt stattdessen Wurzeltyp, Größe und Struktur.
3. 3Auch die Warnungen lesenDoppelte Schlüssel und Zahlen mit Genauigkeitsverlust sind vollkommen legales JSON, das jeder Parser stillschweigend akzeptiert. Sie erscheinen als Warnungen mit einem JSON Pointer, denn genau diese Fehler überleben bis in die Produktion.
4. 4Selbst beheben oder beheben lassenKlicken Sie auf einen Befund, um den Cursor dorthin zu setzen. Ist der Text JSON5, JSONC oder ein Python-Dictionary statt kaputtem JSON, sagt das Werkzeug das und bietet eine reparierte Kopie zum Übernehmen oder Herunterladen an.

Prüfen Sie die Gültigkeit Ihres JSON in Sekunden — mit exakter Fehlerstelle, Parser-Rückmeldung und einer Strukturübersicht für schnelles Debuggen. JSON einfügen oder hochladen und auf Validieren drücken liefert sofort ein Bestanden oder ein Nicht bestanden. Ist es gültig, sehen Sie Wurzeltyp, Größe und einen vollständigen Strukturbericht. Ist es das nicht, sehen Sie alle Fehler auf einmal — jeden mit Zeile, Spalte, Byte-Offset und einer Markierung unter dem genauen Zeichen — dazu die Warnungen, die Ihnen kein anderer Validator zeigt: doppelte Schlüssel und Zahlen, die sich beim Parsen stillschweigend verändern. Alles läuft auf Ihrem Gerät, private Payloads, Token und interne Schemata verlassen es also nie.

• Alle Fehler auf einmal — Ein Parser hält beim ersten Fehler an. Dieser synchronisiert sich neu und macht weiter: Eine Datei mit vierzig Fehlern kostet einen Durchlauf, nicht vierzig.
• Überall dieselbe Stelle — Zeile, Spalte, Byte-Offset und eine Markierung, aus den Bytes berechnet statt aus einer Browsermeldung herausgelesen — in Chrome, Firefox und Safari identisch.
• Die Fehler, die anderswo durchgehen — Doppelte Schlüssel und Zahlen mit Genauigkeitsverlust sind legales JSON. Sie sind auch der Weg, auf dem Daten lautlos verschwinden, also werden sie als Warnungen gemeldet.
• Schema, Dialekte und Reparatur — Gegen ein JSON Schema prüfen, herausfinden, dass Ihre Datei eigentlich JSON5 ist, und mit einem Klick eine reparierte Kopie mitnehmen.
• Einfügen oder hochladen — Aus der Zwischenablage einfügen, eine Datei ablegen oder danach suchen. Zurücksetzen leert Eingabe und Ergebnis gemeinsam.

Das Nützlichste, was ein Validator sagen kann, ist, wo man nachsehen soll — und genau das machen die meisten Online-Validatoren am unzuverlässigsten. Sie geben wieder, was der eingebaute Parser des Browsers sagt, und diese Meldungen sind nicht überall gleich.

In den drei realen Engines gemessen: Safaris Parser meldet „JSON Parse error: Expected '}'“ — ohne Position, ohne Zeile, ohne Spalte. Firefox nennt Zeile und Spalte, aber keinen Zeichen-Offset. Nur Chrome nennt alle drei. Ein Validator, der diese Meldungen mit einem Muster ausliest, funktioniert also in einem von drei Browsern richtig und verschlechtert sich in den übrigen stillschweigend.

• Zeile und Spalte — In Zeichen gezählt, nicht in Bytes, damit eine Zeile, die mit einem Umlaut beginnt, keine Spalte nennt, der Ihr Editor widerspricht.
• Byte-Offset — Das, was Sie brauchen, wenn die Datei von einem Skript und nicht von einem Editor bearbeitet wird.
• Eine Markierung unter dem Fehler — Die betroffene Zeile mit dem genauen Zeichen markiert. Bei einer langen Zeile wird der Ausschnitt um die Fehlerstelle herum beschnitten, nicht am Anfang.
• Ein JSON Pointer — Wo der Fehler in der Struktur des Dokuments sitzt — /users/3/email — und nicht nur im Text.

Ein JSON-Parser soll einen Wert erzeugen; sobald er auf etwas Unbrauchbares trifft, wirft er eine Ausnahme und hält an. Für einen Parser ist das richtig, für einen Validator wenig hilfreich: das fehlende Komma in Zeile 12 beheben, neu ausführen, den Schlüssel ohne Anführungszeichen in Zeile 40 entdecken, neu ausführen.

Dieser Validator baut keinen Wert auf, also hat er nichts aufzugeben. Trifft er auf ein Token, das nirgends passt, notiert er den Fehler und synchronisiert sich neu — behandelt ein fehlendes Komma, als stünde es da, schließt einen Container, der auf die falsche Klammer traf — und läuft bis zum Ende der Datei weiter. Das Ergebnis ist die vollständige Liste in einem Durchlauf. Nach tausend Befunden hört er auf, weit jenseits des Punktes, an dem sich eine Datei von Hand statt neu zu erzeugen lohnt.

• Fehlende Trennzeichen — Ein fehlendes Komma oder ein fehlender Doppelpunkt gilt als Tippfehler und der Durchlauf geht weiter, statt sich in einen Fehler bei jedem folgenden Member fortzupflanzen.
• Nicht passende Klammern — Eine schließende Klammer, die nicht zur öffnenden passt, schließt den Container trotzdem, damit ein einzelner Ausrutscher nicht den Rest der Datei in Rauschen verwandelt.
• Nicht beendete Zeichenketten — Einer Zeichenkette mit fehlendem Anführungszeichen endet am Zeilenende, statt den Rest des Dokuments zu verschlucken.

JSON erlaubt denselben Schlüssel zweimal in einem Objekt. Die Spezifikation sagt nicht, was passieren soll, und die praktische Antwort lautet: Alle gängigen Parser behalten das letzte Vorkommen und verwerfen das erste wortlos.

Eine Konfigurationsdatei mit einem doppelt gesetzten Schlüssel ist also gültig, und die Hälfte davon tut nichts. Eine zusammengeführte API-Antwort mit einem wiederholten Feld ist gültig, und einer der beiden Werte ist weg. Weil es legal ist, bleibt das hier eine Warnung und kein Fehler — das Urteil muss mit dem Parser übereinstimmen, der die Datei tatsächlich verarbeitet — aber es wird mit einem JSON Pointer auf jedes Vorkommen und dem Offset des ersten gemeldet, damit Sie beide sehen.

• Exakt, nicht ungefähr — Schlüssel werden über ihren dekodierten Wert verglichen, sodass ein als "a" geschriebener Schlüssel und derselbe mit einer Escape-Sequenz korrekt als derselbe erkannt werden.
• Pro Objekt, nicht pro Dokument — Derselbe Schlüssel in zwei Geschwisterobjekten ist normal und wird nicht gemeldet. Nur eine Wiederholung innerhalb eines Objekts wird es.
• In jeder Tiefe — Ein Duplikat zwanzig Ebenen tiefer wird gefunden, samt dem Pointer, der dorthin führt.

JSON begrenzt Größe und Genauigkeit von Zahlen nicht, und fast jeder Parser liest sie als 64-Bit-Gleitkommazahl. Oberhalb von 9.007.199.254.740.991 lässt sich eine Ganzzahl nicht mehr exakt darstellen und wird gerundet — stillschweigend, ohne Fehler und ohne Warnung, an keiner Stelle der Kette.

Das ist kein theoretisches Problem. Snowflake-IDs, Twitter-artige Bezeichner, Bestellnummern und Buchungsbeträge liegen alle in diesem Bereich, und das Symptom ist ein Datensatz, der nicht gefunden wird, weil seine ID um ein paar Hundert verschoben zurückkam. Der Validator prüft jedes Zahlenliteral, das betroffen sein könnte, und meldet den exakten Wert neben dem, den ein Parser erzeugen wird.

• Große Ganzzahlen — Exakt verglichen, mit beliebig genauer Arithmetik statt mit dem Gleitkommawert, um den es gerade geht.
• Lange Dezimalzahlen — Eine Dezimalzahl, die sich aus dem Double, zu dem sie wird, nicht zurückgewinnen lässt, wird mit dem Wert gemeldet, auf den sie tatsächlich gerundet wird.
• Überlauf und Unterlauf — 1e400 wird zu Infinity und 1e-400 zu null. Keines ist in JSON darstellbar, und keines löst sonst irgendwo einen Fehler aus.
• Kostenlos, wo es nicht zutrifft — Ein Literal mit fünfzehn Ziffern oder weniger kann nichts verlieren und wird komplett übersprungen. Nur die möglicherweise betroffenen werden untersucht.

Ein großer Teil der Dateien, die als „ungültiges JSON“ gemeldet werden, ist überhaupt nicht kaputt. Sie sind in einem Dialekt geschrieben: JSONC mit Kommentaren und Schlusskommas, oder JSON5, das zusätzlich Schlüssel ohne Anführungszeichen, einfache Anführungszeichen, Hexadezimalzahlen und NaN erlaubt. Ihr Editor liest sie anstandslos; ein strikter Parser weist sie zurück.

tsconfig.json, .eslintrc und die meisten Editor-Einstellungsdateien sind JSONC. Ein aus einer Python-Sitzung kopiertes Dictionary sieht JSON ähnlich, benutzt aber True, False und None. Statt all das kaputt zu nennen, benennt der Validator, was er vor sich hat, listet die verantwortlichen Konstrukte auf und bietet eine Kopie in striktem JSON an.

• Kommentare — Zeilen- und Blockkommentare werden erkannt — und nur außerhalb von Zeichenketten, sodass eine URL mit doppeltem Schrägstrich unangetastet bleibt.
• Schlusskommas — Ein Komma vor der schließenden Klammer, am Komma gemeldet und nicht an der Klammer.
• Anführungszeichen und nackte Schlüssel — Zeichenketten in einfachen Anführungszeichen, Schlüssel ohne Anführungszeichen und die typografischen Anführungszeichen, die eine Textverarbeitung hinterlässt.
• Nicht-JSON-Literale — NaN und Infinity, Hexadezimalzahlen, ein führendes Plus oder ein führender Dezimalpunkt, sowie Pythons True, False und None.

Jede Reparatur stammt aus einem Befund, den der Scanner bereits lokalisiert hat, nie aus einem Muster über das ganze Dokument. Dieser Unterschied wiegt schwerer, als er klingt: Ein regulärer Ausdruck, der Kommentare entfernt, entfernt auch den doppelten Schrägstrich in "https://example.com", und einer, der Schlusskommas entfernt, entfernt auch das Komma in "a, b,". Der Scanner weiß, welche Bytes in einer Zeichenkette standen und welche nicht — beide Fehler stehen ihm gar nicht offen.

Das reparierte Dokument wird anschließend erneut geprüft, bevor es angeboten wird; ist es weiterhin ungültig, wird es als Teilreparatur mit den verbleibenden Fehlern dargestellt. Eine Schaltfläche, die „Repariert“ sagt und etwas zurückgibt, das nicht parst, ist schlechter als gar keine Schaltfläche.

• Was repariert wird — Kommentare, Schlusskommas, einfache und typografische Anführungszeichen, Schlüssel ohne Anführungszeichen, Hexadezimalzahlen, führendes Plus oder führender Punkt sowie Pythons True, False und None.
• Was als verlustbehaftet markiert wird — NaN und Infinity lassen sich in JSON nicht schreiben. Sie werden zu null, und die Änderung wird angesagt statt stillschweigend vorgenommen.
• Übernehmen oder herunterladen — Den reparierten Text direkt zurück in den Editor setzen oder als .json-Datei herunterladen.

Syntax ist nur die halbe Frage. „Hat es die richtige Form?“ ist die andere Hälfte, und die beantwortet ein JSON Schema. Fügen Sie eines in die Seitenleiste ein, und das Dokument wird zusätzlich dagegen geprüft — jeder Fehlschlag mit einem JSON Pointer auf den betroffenen Wert und der Zeile, in der er steht.

Draft 2020-12 und Draft-07 werden unterstützt, und der Draft wird aus $schema gelesen — oder abgeleitet, wenn das Schema ihn nicht angibt, was auf die meisten vor 2020 geschriebenen Schemata zutrifft. Diese Ableitung ist wichtig: Die Array-Form von items bedeutet in Draft-07 etwas anderes als in 2020-12, und die eine als die andere zu lesen liefert eine selbstsichere falsche Antwort statt eines Fehlers.

• Das vollständige Validierungsvokabular — type, enum, const, die Zahlengrenzen, Zeichenkettenlänge und -muster, Array- und Objekteinschränkungen, required und die abhängigen Schlüsselwörter.
• Applikatoren — allOf, anyOf, oneOf, not, if/then/else, prefixItems, contains, propertyNames sowie unevaluatedProperties und unevaluatedItems.
• Referenzen — $ref, $defs, definitions, $anchor und der $id-Gültigkeitsbereich werden innerhalb des von Ihnen gelieferten Schemas aufgelöst. Eine Referenz auf einen anderen Server wird namentlich gemeldet und nie geladen.
• format, so wie die Spezifikation es definiert — Standardmäßig eine Anmerkung, genau wie beide Drafts sagen: Ein Schema mit "format": "email" weist eine falsche Adresse nicht zurück, sofern Sie es nicht verlangen. Für alle, die etwas anderes erwartet haben, gibt es einen Schalter.

Ein JSON-Wert je Zeile — so werden Log-Pipelines, BigQuery-Exporte, Bulk-API-Bodies und Trainingsdatensätze geschrieben. Als einzelnes JSON-Dokument gelesen erzeugt eine solche Datei genau einen Fehler — überzähliger Inhalt am Anfang von Zeile zwei — der technisch korrekt und völlig nutzlos ist.

Der NDJSON-Modus prüft jeden Datensatz für sich, sodass ein Fehler dem Datensatz zugeordnet wird, in dem er steckt. Der Modus wird automatisch vorgeschlagen, wenn eine Datei zeilenweise aussieht, und er wird vorgeschlagen statt angewendet: Ein Werkzeug, das Ihre Eingabe stillschweigend umdeutet, ist eines, über das man nicht nachdenken kann.

• Ergebnisse je Datensatz — Jeder Fehler trägt neben Zeile und Spalte seine Datensatznummer, und die Zahl der bestandenen Datensätze wird daneben gemeldet.
• Der abschließende Zeilenumbruch — Jeder Schreiber beendet den letzten Datensatz mit einem Zeilenumbruch. Diese letzte leere Zeile ist kein Datensatz, und sie als solchen zu behandeln fügt fast jeder korrekt geschriebenen Datei einen Scheinfehler hinzu.
• Windows-Zeilenenden — Ein am Datensatzende stehen gebliebener Wagenrücklauf wäre sonst ein Steuerzeichen im letzten Token — ein Fehler pro Zeile in jeder unter Windows geschriebenen Datei.
• Leere Datensätze — Eine leere Zeile in der Mitte wird gemeldet statt übersprungen. Das Format kennt keinen Platzhalter, eine leere Zeile heißt also, dass ein Datensatz leer geschrieben wurde.

Eine Datei kann vollkommen korrektes JSON sein und trotzdem an drei unsichtbaren Bytes scheitern. Eine UTF-8-Bytereihenfolge-Marke — was PowerShells Out-File, .NETs StreamWriter und Excels „UTF-8“-Export alle schreiben — steht vor der öffnenden Klammer, und ein strikter Parser meldet ein unerwartetes Token an Position 0 für ein ansonsten makelloses Dokument.

UTF-16 ist schlimmer, denn das schreibt Windows PowerShell, wenn gar keine Kodierung angegeben wird. Als UTF-8 gelesen sieht es aus wie ein NUL-Byte nach jedem Zeichen, und der Fehler zeigt auf etwas, das niemand sehen kann. Beides wird hier erkannt und behandelt, und die verwendete Kodierung wird gemeldet, damit nichts hinter Ihrem Rücken passiert.

• UTF-8, mit oder ohne Marke — Die Marke wird erkannt, entfernt und gemeldet. Das Dokument wird validiert, als wäre sie nie da gewesen.
• UTF-16, mit oder ohne Marke — Erkannt an der Marke oder daran, wo die NUL-Bytes liegen — JSONs Strukturzeichen sind alle ASCII, das Muster ist also schlüssig und keine Vermutung.
• Fehlerhafte Bytes — Ein Byte, das kein gültiges UTF-8 ist, wird als Warnung gemeldet, nicht als Urteil: Ein Browser ersetzt es, bevor irgendein Parser es sieht, es kann ein Dokument also nicht ungültig machen — es heißt aber, dass die Datei nicht in der Kodierung vorliegt, die sie vorgibt.
• Überhaupt kein Text — Ein in .json umbenanntes Bild wird mit genau diesem Grund abgelehnt, statt für etwas, das nie JSON war, einen Syntaxfehler an Position 0 zu erzeugen.

Ein einziger Durchlauf über die rohen Bytes, ohne dass etwas irgendwohin gesendet wird. Ein 22-MB-Dokument wird auf einem normalen Laptop in etwa 0,2 Sekunden geprüft — einschließlich doppelter Schlüssel und Zahlengenauigkeit — weil der Scanner die Werte, die er prüft, nie aufbaut.

• Gültig — Ein grünes Urteil mit Wurzeltyp und Größe sowie ein Strukturbericht: Gesamtzahl der Knoten, maximale Tiefe, Anzahl von Objekten, Arrays und Schlüsseln, die Größe in Zeilen und Bytes und die verwendete Kodierung.
• Ungültig — Ein rotes Urteil mit allen aufgelisteten Fehlern — Zeile, Spalte, JSON Pointer, eine klare Beschreibung und eine Markierung unter dem genauen Zeichen — dazu ein Link zum JSON-Formatierer.
• Warnungen — Doppelte Schlüssel, Zahlen mit Genauigkeitsverlust, unvollständige Surrogatpaare und ungewöhnlich tiefe Verschachtelung, jeweils mit Fundstelle. Sie ändern das Urteil nicht, denn ein Parser wird sie akzeptieren.
• Ein Dialekt, wenn es einen gibt — Ist der Text gültiges JSON5, JSONC oder ein Python-Dictionary, wird das ausdrücklich gesagt, mit der Möglichkeit zur Umwandlung.

Ungültiges JSON zerbricht APIs, Konfigurationen und Datenpipelines — und meist weit entfernt von der Stelle, an der der Fehler sitzt. Vor dem Senden oder Speichern zu prüfen fängt Tippfehler, fehlende Kommas, Schlusskommas und nicht maskierte Zeichen ab, solange Sie die Datei noch vor sich haben. Die Warnungen wiegen schwerer: Ein doppelter Schlüssel oder eine gerundete Kennung erzeugt nirgends einen Fehler, übersteht also jeden Test und taucht Wochen später als fehlende Daten auf. Alle Prüfungen laufen lokal, Ihre Daten bleiben privat.

• Fehler früh finden — Syntaxprobleme finden, bevor sie ein Deployment oder eine Integration zerbrechen — mit exakter Zeile und Spalte statt einem Stacktrace von einem Server.
• Die stillen finden — Doppelte Schlüssel und Genauigkeitsverlust kommen an jedem Parser und jedem bestehenden Validator vorbei. Das sind die Fehler, die in die Produktion gelangen.
• Die Form prüfen, nicht nur die Syntax — Ein JSON Schema macht aus „es parst“ ein „es ist, was der Konsument erwartet“ — bevor der Konsument es herausfindet.
• Datenschutz — Nichts wird hochgeladen. Private API-Antworten, Zugriffstoken und interne Schemata lassen sich prüfen, ohne Ihr Gerät zu verlassen.

Alles, was über die Gültigkeit eines Dokuments entscheidet, ist kostenlos. Alle Fehler statt nur des ersten, doppelte Schlüssel, Genauigkeitswarnungen, JSON Schema, Dialekterkennung, Reparatur, NDJSON-Modus und der vollständige Strukturbericht stehen kostenlos zur Verfügung. Pro fügt Umfang hinzu, keine Funktionen.

• Kostenlos — Eine Datei auf einmal, bis 25 MB, dazu unbegrenztes Einfügen. Alle Prüfungen, alle Warnungen, Schemaprüfung und Reparatur inbegriffen.
• Pro — Bis zu 100 Dateien in einem Durchlauf, Größen begrenzt durch Ihr Gerät statt durch uns, ein ZIP mit Berichten für den ganzen Stapel und maschinenlesbare JSON- und CSV-Berichte für einen CI-Schritt oder ein Ticket.
• Warum 25 MB — Das ist eine Messung, keine runde Zahl. Ein 22-MB-Dokument wird in etwa 0,2 Sekunden geprüft — die Grenze liegt also dort, wo ein Mittelklasse-Smartphone noch bequem mitkommt.

• JSON-Formatierer
• JSON minifizieren
• JSON-Betrachter
• JSON vergleichen
• JSON-Schlüssel sortieren
• JSON-Schlüssel entfernen