JSON formatieren

So formatieren Sie JSON in vier Schritten

1. Fügen Sie Ihr JSON in das Feld JSON-Eingabe ein.
2. Klicken Sie auf Formatieren / Verschönern, um es sauber einzurücken (2 Leerzeichen, 4 Leerzeichen oder Tabulator), auf Minifizieren, um alle Leerzeichen zu entfernen, oder auf Prüfen, wenn Sie es nur kontrollieren möchten.
3. Ist das JSON ungültig, nennt die Meldung die genaue Zeile und Spalte des Fehlers.
4. Das Ergebnis können Sie kopieren oder als Datei herunterladen.

Formatieren, prüfen, minifizieren – der Unterschied

Prüfen kontrolliert, ob Ihr Text wohlgeformtes JSON ist. Formatieren (Verschönern) rückt gültiges JSON neu ein, damit ein Mensch verschachtelte Strukturen lesen kann. Minifizieren entfernt jedes überflüssige Leerzeichen und jeden Zeilenumbruch, damit die Daten so klein wie möglich werden – praktisch, bevor Sie JSON über das Netz schicken oder es irgendwo einbetten. Keiner dieser Schritte ändert Ihre Daten: Schlüssel, Werte, Datentypen und die Reihenfolge der Schlüssel bleiben genau so, wie Sie sie geschrieben haben. Nur die Leerzeichen sind anders.

Häufige Gründe, warum JSON ungültig ist

• Komma am Ende – {"a":1,} ist ungültig; nach dem letzten Element darf kein Komma stehen.
• Einfache Anführungszeichen – Zeichenketten und Schlüssel brauchen "doppelte Anführungszeichen", niemals '.
• Schlüssel ohne Anführungszeichen – aus {name:"x"} muss {"name":"x"} werden.
• Kommentare – JSON kennt weder // noch /* */.
• Falsch geschriebene Schlüsselwörter – Wahrheitswerte und null werden kleingeschrieben (true, false, null); reine JavaScript-Schlüsselwörter sind kein gültiges JSON.
• Klammern passen nicht zusammen – zu jeder { und jeder [ gehört eine schließende Klammer.

Bleiben meine Daten privat?

Ja. Das Werkzeug nutzt JSON.parse und JSON.stringify direkt in Ihrem Browser – nichts geht an einen Server. Sie können also gefahrlos interne API-Antworten, Zugangstoken oder Konfigurationsdateien einfügen. Nach dem Laden der Seite funktioniert alles auch offline.

Was ist JSON, und woher kommt es?

JSON (JavaScript Object Notation) ist ein schlankes, textbasiertes Format für den Austausch strukturierter Daten. Benannt und bekannt gemacht hat es Douglas Crockford, der 2002 die Domain json.org registrierte und dort die Grammatik veröffentlichte. Die Syntax stammt von den Objekt- und Array-Literalen der Sprache JavaScript, genauer vom ECMAScript 3-Standard aus dem Jahr 1999. JSON selbst ist aber sprachunabhängig: Für praktisch jede Programmiersprache gibt es Parser und Serialisierer. Genau deshalb wurde es zum Standardweg, auf dem ein Browser, eine Mobil-App und ein Server miteinander sprechen – auch wenn alle drei in verschiedenen Sprachen geschrieben sind.

Erstmals schriftlich festgehalten wurde JSON als IETF-Spezifikation RFC 4627 (2006). Im Oktober 2013 bekam es mit ECMA-404 eine formale Grammatik von einem Normungsgremium, und die heute maßgebliche Spezifikation ist RFC 8259 (2017), die zugleich als Internet-Standard STD 90 veröffentlicht ist. RFC 8259 hat eine Regel klargestellt, die ältere Dokumente offen ließen: JSON-Text, der zwischen Systemen ausgetauscht wird, muss in UTF-8 kodiert sein. Die beiden lebenden Spezifikationen, ECMA-404 und RFC 8259, werden bewusst inhaltsgleich gehalten; ihre Herausgeber haben vereinbart, beide immer gemeinsam zu ändern.

Die sechs Datentypen in JSON

Jeder Wert in einem JSON-Dokument gehört zu genau einem von sechs Typen – mehr gibt es nicht:

• Object – eine ungeordnete Menge von "key": value-Paaren in geschweiften Klammern. Schlüssel müssen Zeichenketten in doppelten Anführungszeichen sein.
• Array – eine geordnete Liste von Werten in eckigen Klammern. Die Werte dürfen gemischte Typen haben.
• String – Text in doppelten Anführungszeichen, mit Escapes wie \n, \t, \" und \uXXXX.
• Number – eine Dezimalzahl wie 42, -3.14 oder 6.022e23. Einen eigenen Ganzzahltyp gibt es nicht, und NaN, Infinity sowie führende Nullen sind nicht erlaubt.
• Boolean – die kleingeschriebenen Werte true oder false.
• Null – der kleingeschriebene Wert null, also „kein Wert“.

Ein JSON-Dokument ist schlicht ein Wert eines dieser Typen – meist ein Objekt oder ein Array auf der obersten Ebene. RFC 8259 erlaubt allerdings jeden Wert als vollständigen JSON-Text, sogar ein einzelnes true oder eine einzelne Zahl.

Warum JSON so streng sein muss

JSON ist mit Absicht eine strenge Teilmenge der JavaScript-Syntax – strenger sogar als die Objekte, die Sie im Code schreiben. Diese Strenge ist ein Vorteil: Eine starre Grammatik sorgt dafür, dass jeder Parser ein Dokument gleich liest, ohne Spielraum für Auslegung. Genau die Regeln, über die viele stolpern, folgen direkt aus dieser Entscheidung. Es gibt keine Kommentare – Crockford hat sie bewusst gestrichen, damit niemand Anweisungen an den Parser in einer Datendatei verstecken kann. Es gibt kein Komma nach dem letzten Element, denn ein Komma trennt und darf am Ende nicht stehen. Für Schlüssel und Zeichenketten sind nur doppelte Anführungszeichen zulässig; die einfachen Anführungszeichen und Schlüssel ohne Anführungszeichen, die JavaScript erlaubt, sind kein gültiges JSON. Und true, false sowie null achten auf Groß- und Kleinschreibung: True oder NULL führen zum Fehler.

Die Falle mit großen Zahlen

JSON begrenzt weder Größe noch Genauigkeit einer Zahl. Die meisten Parser – auch das JSON.parse in Ihrem Browser – lesen Zahlen jedoch als 64-Bit-Gleitkommawerte nach IEEE 754 ein. Damit lassen sich ganze Zahlen nur bis 2⁵³ − 1 sicher darstellen (9007199254740991, in JavaScript als Number.MAX_SAFE_INTEGER verfügbar). Eine größere 64-Bit-Datenbank-ID oder ein sehr langer numerischer Token wird beim Einlesen stillschweigend gerundet. Der übliche Ausweg: Solche Werte als Zeichenkette übertragen und erst dort umwandeln, wo ein Typ für große Ganzzahlen zur Verfügung steht. Vor diesem Fehler kann kein Formatierer warnen, denn das Runden passiert schon im Parser, bevor der Wert überhaupt auf der Seite ankommt.

JSON, XML und YAML im Vergleich

Vor JSON war XML das vorherrschende Austauschformat. XML kann viel – Attribute, Namensräume, Schemata (XSD) und Validierung – ist aber geschwätzig: Jedes Element braucht ein öffnendes und ein schließendes Tag, was die Datenmenge und den Aufwand beim Einlesen erhöht. JSON drückt dieselben Daten mit deutlich weniger Text aus und bildet die eingebauten Strukturen der meisten Sprachen (Objekte, Arrays, Maps, Listen) direkt ab. Deshalb sind REST-Schnittstellen fast vollständig darauf umgestiegen.

YAML ist fast eine Obermenge von JSON und ergänzt Kommentare, Anker und ein Layout über Einrückungen. Das macht es beliebt für Konfigurationen, die Menschen von Hand pflegen, etwa CI-Pipelines und Kubernetes-Manifeste. Der Preis dafür: YAML reagiert empfindlich auf Einrückungen und ist beim Bearbeiten schnell kaputt, während die ausdrücklichen Klammern von JSON eindeutig sind. Eine brauchbare Faustregel: JSON für Maschinen, YAML für Menschen, XML für Dokumente mit reichem Markup und gemischten Inhalten.

Die lockeren Verwandten: JSON5, JSONC und NDJSON

Mehrere Erweiterungen lockern die JSON-Regeln für bestimmte Zwecke. JSONC („JSON with Comments“) erlaubt schlicht Kommentare mit // und /* */ und wird von Visual Studio Code für die Einstellungsdateien verwendet. JSON5 geht weiter und lässt einfache Anführungszeichen, Schlüssel ohne Anführungszeichen, ein Komma am Ende und Hexadezimalzahlen zu, damit von Hand gepflegte Dateien nachsichtiger sind. NDJSON (auch JSON Lines genannt) speichert pro Zeile ein eigenständiges JSON-Objekt und eignet sich damit für laufende Protokolle und große Datenmengen, weil ein Programm einen Datensatz nach dem anderen verarbeiten kann, ohne die ganze Datei zu laden. Keine dieser Varianten ist mit striktem JSON austauschbar: Erwartet ein Server JSON nach RFC 8259, werden Kommentare und ein Komma am Ende abgelehnt. Das ist der mit Abstand häufigste Grund, warum sich Daten, die „eigentlich richtig aussehen“, nicht einlesen lassen.

Wo Ihnen JSON überall begegnet

Wer einmal darauf achtet, sieht JSON überall. Es ist das Format für den Rumpf der allermeisten REST- und GraphQL-Schnittstellen; die Konfigurationssprache unzähliger Werkzeuge (package.json, tsconfig.json, composer.json); das native Dokumentformat von NoSQL-Datenbanken wie MongoDB; und der Inhalt jedes JSON Web Token. Spezielle Dialekte erschließen weitere Bereiche: GeoJSON beschreibt Karten und geografische Formen, JSON-LD liefert die strukturierten Daten, die Suchmaschinen auslesen, und JSON Schema beschreibt und prüft den Aufbau anderer JSON-Dokumente. JSON gut zu kennen zahlt sich in der Softwareentwicklung besonders aus, weil dasselbe Format an so vielen Stellen wieder auftaucht.

Verschönern oder minifizieren? Es kommt auf den Leser an

Verschönertes JSON mit Einrückungen und Zeilenumbrüchen ist für einen Leser gemacht: den Menschen. Minifiziertes JSON, aus dem jedes verzichtbare Leerzeichen entfernt wurde, ist für einen anderen gemacht: das Netz. Daten, die gleich über die Leitung gehen, sollten Sie minifizieren – denken Sie aber daran, dass HTTP-Antworten fast immer mit gzip oder Brotli komprimiert werden und Kompression wiederkehrende Leerzeichen ohnehin sehr wirksam zusammenfasst. Nach der Kompression fällt der Größenunterschied deshalb meist gering aus. Der eigentliche Gewinn beim Minifizieren sind schlicht weniger Bytes, die eingelesen werden müssen. Alles, was Sie lesen, debuggen, in die Versionsverwaltung einchecken oder in einen Fehlerbericht einfügen, sollten Sie dagegen zuerst verschönern: Eine saubere, eingerückte Struktur macht eine fehlende Klammer oder einen falsch platzierten Wert auf einen Blick sichtbar.

Eine Anmerkung zu JSON und Sicherheit

JSON einzulesen ist sicher; es auszuführen nicht. In den Anfangsjahren haben manche Entwicklerinnen und Entwickler JSON verarbeitet, indem sie es an eval() in JavaScript übergaben. Damit lief jeder Code mit, der im Text versteckt war – eine ernste Sicherheitslücke. Verwenden Sie immer einen echten Parser wie JSON.parse, den auch dieses Werkzeug nutzt, und niemals eval. Eine Feinheit ist gut zu wissen: Ein Schlüssel namens __proto__ in fremdem JSON wurde in manchen Bibliotheken für Angriffe durch „Prototype Pollution“ ausgenutzt. Gepflegte Parser schützen inzwischen davor, doch es bleibt ein guter Grund, fremdes JSON nie direkt in Code zu geben, der Objekte zusammenführt.

JSON kennt keinen Datumstyp

Viele überrascht, dass JSON keine eigene Darstellung für Datum, Uhrzeit oder Binärdaten hat – es gibt nur die sechs Typen von oben. Nach einer sehr verbreiteten Konvention werden Datumsangaben als ISO 8601-Zeichenketten übertragen, etwa "2026-06-30T14:00:00Z", und Binärdaten als Base64-kodierte Zeichenketten. Wenn Sie ein JavaScript-Date mit JSON.stringify serialisieren, erhalten Sie automatisch eine ISO 8601-Zeichenkette. Lesen Sie sie wieder ein, bekommen Sie aber eine Zeichenkette zurück und kein Date – das müssen Sie selbst umwandeln. Jeden Zeitstempel als UTC zu behandeln (erkennbar am abschließenden Z) und erst für die Anzeige in Ortszeit umzurechnen, ist der zuverlässigste Weg, Fehler mit Zeitzonen zu vermeiden.

Doppelte Schlüssel und ihre Reihenfolge

Zwei weitere Punkte sorgen regelmäßig für Verwirrung. Erstens sagt RFC 8259, dass die Namen innerhalb eines Objekts eindeutig sein sollten, verbietet Doppelungen aber nicht – und lässt offen, wie sich ein Parser verhalten muss, der einen Schlüssel zweimal antrifft. In der Praxis behalten die meisten Parser, auch der im Browser, das letzte Vorkommen. Verlassen sollten Sie sich darauf nie: Doppelte Schlüssel sind eine klassische Quelle für Fehler zwischen Systemen. Zweitens gilt ein JSON-Objekt formal als ungeordnete Sammlung, doch jeder gängige Parser behält die Reihenfolge bei, in der die Schlüssel eingefügt wurden. Auch dieser Formatierer lässt Ihre Schlüssel beim Verschönern und Minifizieren genau in der Reihenfolge, in der Sie sie geschrieben haben. Hängt Ihre Anwendung wirklich an einer bestimmten Reihenfolge, kodieren Sie diese ausdrücklich – zum Beispiel als Array von Paaren – statt sich auf die Schlüsselreihenfolge im Objekt zu verlassen.

In JSON navigieren: JSONPath und JSON Pointer

Je größer die Dokumente werden, desto mehr brauchen Sie eine Möglichkeit, einen Wert tief im Inneren anzusprechen. Dafür gibt es zwei kleine Standards. JSON Pointer (RFC 6901) verwendet einen Pfad mit Schrägstrichen wie /users/0/email und zeigt damit auf genau eine Stelle – so verweisen JSON Patch und JSON Schema intern auf einen Knoten. JSONPath ist eine ausdrucksstärkere, abfrageähnliche Schreibweise (angelehnt an XPath für XML), die mehrere Knoten auf einmal auswählen, nach Bedingungen filtern und Platzhalter verwenden kann – etwa $.users[*].email für die E-Mail-Adresse aller Nutzer. Der Pointer beantwortet „diese eine Stelle“, JSONPath „alles, was passt“. Schon zu wissen, dass es beides gibt, erspart viel Suchen von Hand in einem großen, verschönerten Dokument.

Tipps für große JSON-Dateien

Werkzeuge im Browser, auch dieses hier, bewältigen Dateien von mehreren Megabyte ohne Mühe, weil die Arbeit lokal auf Ihrem Rechner passiert. Werden Dokumente wirklich groß, helfen ein paar Gewohnheiten. Verschönern Sie vor dem Lesen, damit die Struktur sichtbar wird, und behalten Sie eine minifizierte Fassung für die Übertragung. Für Dateien, die nicht mehr komplett in den Speicher passen, eignet sich NDJSON (ein Objekt pro Zeile), das Sie Zeile für Zeile verarbeiten, oder ein Streaming-Parser, der Werte schon beim Lesen ausgibt, statt erst den ganzen Baum aufzubauen. Und wenn eine Schnittstelle eine große Sammlung liefert, suchen Sie nach Seitenaufteilung – einem next-Cursor oder einem Seitenparameter – statt alles auf einmal anzufordern. Gut entworfene Schnittstellen erwarten nie, dass Sie eine Million Datensätze in einer einzigen Antwort herunterladen.

Häufige Fragen

Wird mein JSON auf einen Server hochgeladen?

Nein. Das Formatieren, Prüfen und Minifizieren läuft vollständig in Ihrem Browser mit JavaScript. Ihre Daten verlassen Ihr Gerät nicht. Deshalb ist das Werkzeug schnell, und Sie können auch vertrauliche Inhalte wie interne API-Antworten oder Konfigurationsdateien bedenkenlos einfügen.

Warum ist mein JSON ungültig?

Die häufigsten Ursachen sind ein Komma hinter dem letzten Element, einfache statt doppelter Anführungszeichen, Schlüssel ohne Anführungszeichen, Kommentare (die es in JSON nicht gibt) oder eine fehlende Klammer. Dieses Werkzeug zeigt Ihnen genau die Zeile und die Spalte, an der das Einlesen gescheitert ist.

Was ist der Unterschied zwischen Formatieren, Prüfen und Minifizieren?

Beim Prüfen wird nur kontrolliert, ob der Text überhaupt gültiges JSON ist. Beim Formatieren („Verschönern“) wird gültiges JSON neu eingerückt, damit man es gut lesen kann. Beim Minifizieren fallen alle Leerzeichen und Zeilenumbrüche weg, damit die Daten so klein wie möglich werden. Dieses Werkzeug kann alle drei Schritte in einem einzigen Feld.

Ändert das Formatieren meine Daten?

Nein. Verschönern und Minifizieren ändern nur die Leerzeichen. Schlüssel, Werte, Datentypen und die Struktur bleiben identisch, und die Reihenfolge der Schlüssel bleibt genau so, wie Sie sie geschrieben haben.

Wie große Dateien kann das Werkzeug verarbeiten?

Weil alles im Browser läuft, bewältigt es übliche API-Antworten und Konfigurationsdateien von mehreren Megabyte ohne Mühe. Bei sehr großen Dateien setzt allein der Arbeitsspeicher Ihres Geräts die Grenze – ein Upload-Limit gibt es nicht.

Passende Entwickler-Tools

• JSON zu CSV
• JSON zu XML
• JSON zu HTML-Tabelle
• CSV zu JSON
• Base64-Encoder / -Decoder

Alle Entwickler- und Datenumrechnungen ansehen →