Häufige Fragen zu JSON

JSON (JavaScript Object Notation) ist ein textbasiertes Datenformat zum Austausch strukturierter Daten. Es wurde 2001 von Douglas Crockford spezifiziert und ist seit RFC 8259 (Dezember 2017) der IETF-Standard. JSON kennt sieben Datentypen: Object, Array, String, Number, Boolean, null und das Dokument selbst.

JSON ist das de-facto Standardformat für REST-APIs, Konfigurationsdateien, DOM-Datenbankexports (MongoDB) und Browser-Server-Kommunikation. Es hat XML im Web fast komplett verdrängt, weil es kompakter, schneller zu parsen und in JavaScript natürlich darstellbar ist.

Sieben: Object (Key-Value-Map in geschweiften Klammern), Array (geordnete Liste in eckigen Klammern), String (mit Double-Quotes), Number (Integer oder Float), Boolean (true/false), null und das Dokument als Wurzel-Container. Datums-Werte, Binärdaten und BigInt sind nicht nativ vorgesehen - meistens als String repräsentiert.

JSON ist strikt nach RFC 8259: keine Kommentare, keine trailing Commas, Double-Quotes Pflicht. JSONC erlaubt zusätzlich //- und /* */-Kommentare - wird in tsconfig.json und VS-Code-Settings genutzt. JSON5 geht weiter: zusätzlich trailing Commas, Single-Quotes, hex-Zahlen, NaN/Infinity, unzitierte Keys. Beide brauchen spezielle Parser.

Die häufigsten Ursachen: 1) Trailing-Comma am Ende eines Objects oder Arrays, 2) Single-Quotes statt Double-Quotes, 3) unquoted Keys, 4) JavaScript-Kommentare im JSON, 5) UTF-8-BOM am Datei-Anfang (besonders unter Windows). Unser Tool zeigt die genaue Fehlerzeile an.

Nein, striktes JSON nach RFC 8259 erlaubt keine Kommentare. Wenn Sie Kommentare brauchen, nutzen Sie JSONC (für tsconfig.json üblich) oder JSON5. Alternativer Workaround: ein Object-Key "_comment" einbauen, der inhaltlich ignoriert wird.

Verpflichtend escaped: " (Double-Quote) als \", \ (Backslash) als \\, sowie die Steuerzeichen \b \f \n \r \t. Optional: / (Slash) als \/ - nützlich in </script>-Inhalten. Beliebige Unicode-Codepoints können als \uXXXX (vier Hex-Stellen) escaped werden.

Laut RFC 8259 ist das Verhalten "implementation-defined" - die Spezifikation verbietet es nicht, empfiehlt aber Eindeutigkeit. JavaScript JSON.parse behält den letzten Wert. Andere Parser werfen einen Fehler. Verlassen Sie sich nicht darauf - verwenden Sie immer eindeutige Keys.

Ja, vollständig kostenlos und ohne Anmeldung. Es gibt keine Limits, keine Premium-Features. Der Formatter läuft komplett client-seitig in Ihrem Browser - wir sehen Ihre Daten nie.

Nein. Die Verarbeitung passiert komplett im Browser via JSON.parse/JSON.stringify. Keine Server-Uploads. Optional speichert Ihr Browser die letzten 5 Eingaben in LocalStorage - verlässt aber niemals Ihr Gerät.

Ja, bis circa 10-20 MB ohne Probleme. Bei größeren Dateien (> 100 MB) leidet die Browser-Performance - dann lieber serverseitig mit Streaming-Parser arbeiten. Unser Tool warnt ab 500 KB vor möglichen Performance-Effekten.

Pretty-Print fügt Einrückungen (2, 3 oder 4 Leerzeichen) und Zeilenumbrüche ein - lesbar für Menschen, ideal für Git-Diffs. Minify entfernt allen Whitespace - kompakteste Form, spart bei der Übertragung. Nach gzip-Komprimierung ist der Unterschied allerdings marginal.

JSON: API-Payloads, Datenexport, Streaming, automatisierte Generierung. YAML: Konfigurationsdateien zum manuellen Editieren (Kubernetes, Docker-Compose, CI-Pipelines). JSON ist strenger und schneller zu parsen, YAML lesbarer aber mit Pitfalls (das berühmte Norway-Problem mit yes/no/on/off).

JSON hat keinen nativen Date-Typ. Die Konvention ist ISO 8601 als String: "2026-05-14T12:34:56+01:00". JSON.parse gibt einen String zurück - die Date-Deserialisierung muss man selbst machen, oder via reviver-Callback in JSON.parse(text, reviver).

Mit JSON Schema (Draft 2020-12). Library der Wahl in Node.js ist Ajv: Schema einmal kompilieren, dann millionenfach validieren. Schema beschreibt Typen, Required-Fields, Patterns, Min/Max, Enums und konditionale Logik deklarativ.

application/json - registriert bei IANA, definiert in RFC 8259. Spezialvarianten: application/problem+json für Error-Responses (RFC 7807), application/ld+json für JSON-LD (Schema.org), application/json-patch+json für JSON-Patch-Operationen.

Nein, JSON.parse ist hoch-optimiert. In V8/Chrome 130 erreicht es typisch 1 GB/s auf modernen CPUs. Für Payloads unter 5 MB ist Parsing fast nie das Bottleneck. Erst ab 100 MB+ lohnt Streaming-Parsing. SIMD-beschleunigte Libraries wie simdjson sind nur in C++-Anwendungen relevant.