Was ist eine JSON Datei? Aufbau, Fehler und Praxis erklärt (2026)

Irgendwann liegt sie da: eine Datei namens config.json, package.json oder export.json. Ein Doppelklick öffnet entweder gar nichts, einen Browser mit einer Baumansicht oder einen Editor mit einer einzigen, endlos langen Zeile voller geschweifter Klammern.

Eine JSON Datei ist eine reine Textdatei, die strukturierte Daten in einem festgelegten Format speichert. JSON steht für JavaScript Object Notation. Sie enthält keine Programmlogik, keine Formatierung und keine versteckten Metadaten — nur Werte, Namen und die Verschachtelung dazwischen. Jedes Programm, das Text lesen kann, kann eine JSON Datei öffnen; jede gängige Programmiersprache bringt einen Parser dafür mit.

Dieser Artikel erklärt das von Grund auf: was in so einer Datei steht, welche Datentypen es gibt, warum der Parser bei einem einzigen zusätzlichen Komma aussteigt, wie sich JSON von YAML, TOML und den Varianten JSONC, JSON5 und NDJSON unterscheidet, was bei großen Dateien passiert — und an welchen zwei Stellen JSON zu einem Sicherheitsproblem wird. Alle Zahlen und Fehlermeldungen in diesem Artikel stammen aus Messungen auf unserem eigenen Server, nicht aus der Dokumentation.

Die kurze Antwort in sechs Sätzen

1. Eine JSON Datei ist reiner Text — dieselbe Sorte Daten wie in einer .txt-Datei.
2. Sie speichert Werte mit Namen, beliebig tief ineinander verschachtelt.
3. Es gibt genau sechs Datentypen: Zeichenkette, Zahl, Wahrheitswert, null, Array und Objekt.
4. Die Syntax ist extrem streng — ein überzähliges Komma macht die ganze Datei unlesbar.
5. Jede Programmiersprache kann sie lesen; JSON ist kein JavaScript-Feature, auch wenn der Name das nahelegt.
6. Öffnen kannst du sie mit jedem Texteditor, komfortabler mit einem Editor, der Syntax einfärbt.

Der wichtigste Satz für alle, die eine JSON Datei nur ansehen wollen: Du brauchst keine spezielle Software. Notepad, TextEdit, nano, VS Code — alles funktioniert. Die Datei ist lesbar, sobald sie umgebrochen und eingerückt ist.

Wie eine JSON Datei aufgebaut ist

Das folgende Beispiel enthält alles, was JSON überhaupt kann:

{
  "name": "getmind",
  "version": 2,
  "aktiv": true,
  "beschreibung": null,
  "tags": ["blog", "technik", "deutsch"],
  "autor": {
    "vorname": "Fabian",
    "rollen": ["entwicklung", "redaktion"]
  }
}

Die Bausteine:

• Objekt — steht in geschweiften Klammern {} und enthält Paare aus Name und Wert. Der Name steht immer in doppelten Anführungszeichen.
• Array — steht in eckigen Klammern [] und enthält eine geordnete Liste von Werten. Die Werte dürfen unterschiedliche Typen haben, auch wenn das selten sinnvoll ist.
• Zeichenkette — doppelte Anführungszeichen, immer. Einfache sind verboten.
• Zahl — ohne Anführungszeichen, mit Punkt als Dezimaltrenner, optional mit Exponent (1.5e3).
• Wahrheitswert — true oder false, kleingeschrieben.
• Nichts — null, kleingeschrieben.

Ganz außen steht üblicherweise ein Objekt oder ein Array. Erlaubt ist aber auch ein einzelner Wert: 42, "hallo" oder true sind für sich genommen gültige JSON-Dokumente. Das überrascht viele und ist der Grund, warum manche APIs eine nackte Zahl zurückgeben dürfen.

Was JSON bewusst NICHT kann

Diese Liste erklärt die meisten Frustrationsmomente:

• Keine Kommentare. Es gibt keine offizielle Syntax dafür. Das war eine ausdrückliche Entscheidung des Erfinders Douglas Crockford — Kommentare wurden früher benutzt, um Parser-Anweisungen einzuschmuggeln.
• Keine Datumsangaben. JSON kennt keinen Datumstyp. Zeitangaben sind immer Zeichenketten, üblicherweise im Format 2026-09-16T07:00:00Z (ISO 8601).
• Keine Kommentarzeilen, keine Variablen, keine Verweise. Eine JSON Datei kann nicht auf sich selbst verweisen.
• Kein abschließendes Komma. Nach dem letzten Eintrag darf kein Komma stehen — der häufigste Fehler überhaupt.
• Keine Zeichenkodierung außer UTF-8 in der Praxis. Der Standard erlaubt theoretisch mehr, alle relevanten Parser erwarten UTF-8.

Wie du eine JSON Datei öffnest

Je nachdem, was du vorhast:

Nur ansehen: Zieh die Datei in ein Browserfenster. Firefox und Chrome haben eine eingebaute JSON-Ansicht mit auf- und zuklappbarem Baum. Das ist der schnellste Weg und verlangt keine Installation.

Bearbeiten: VS Code, Notepad++, Sublime Text oder jeder andere Code-Editor. Diese Programme färben die Syntax ein und markieren Fehler rot, während du tippst — das spart die spätere Fehlersuche.

Formatieren (die berüchtigte eine lange Zeile): Viele Dateien werden ohne Zeilenumbrüche gespeichert, weil das Bytes spart. Einrücken kannst du sie in jedem Editor oder auf der Kommandozeile:

# mit jq (Standardwerkzeug auf Servern)
jq . datei.json > lesbar.json

# mit Python, ohne Zusatzinstallation
python3 -m json.tool datei.json

# mit Node.js
node -e "console.log(JSON.stringify(require('./datei.json'), null, 2))"

Auf dem Server durchsuchen: jq ist das Werkzeug der Wahl. jq '.autor.vorname' datei.json holt gezielt einen Wert heraus, ohne die Datei zu öffnen.

Was du nicht tun solltest: JSON Dateien in Word oder einem Textverarbeitungsprogramm öffnen. Word ersetzt gerade Anführungszeichen automatisch durch typografische („smarte”) — und macht die Datei damit unbrauchbar. Wie unbrauchbar, zeigt der nächste Abschnitt.

Die häufigsten Syntaxfehler — mit den echten Fehlermeldungen

JSON verzeiht nichts. Wir haben elf typische Fehler durch den Parser von Node.js 22 geschickt und die Meldungen mitgeschrieben, statt sie zu beschreiben:

Zwei Dinge fallen daran auf.

Erstens: Die Positionsangabe zeigt oft nicht auf die Ursache. Beim abschließenden Komma meldet der Parser Position 7 — das ist die schließende Klammer, nicht das Komma auf Position 6. Der Parser merkt erst dort, dass etwas fehlt, was das Komma versprochen hatte. Bei einer 4000-Zeilen-Datei suchst du deshalb nicht an der gemeldeten Stelle, sondern direkt davor.

Zweitens: Die BOM-Meldung ist irreführend. Der Text hinter „Unexpected token” sieht aus wie gültiges JSON: {"a":1}. Das Byte, das stört, ist unsichtbar — ein Byte-Order-Mark, das manche Windows-Editoren beim Speichern vorne anhängen. Die Datei sieht in jedem Editor korrekt aus und ist trotzdem kaputt. Wenn eine Datei „eigentlich richtig” aussieht und der Parser trotzdem meckert, prüfe zuerst das:

file datei.json            # meldet "with BOM", falls vorhanden
head -c 3 datei.json | xxd # EF BB BF = BOM

Dieselbe Datei, ein anderer Parser, ein anderes Ergebnis

Hier wird es unangenehm: Parser sind sich nicht einig. Wir haben dieselben Eingaben gegen Python 3 laufen lassen:

Python akzeptiert NaN und Infinity — beides steht nicht im JSON-Standard. Schlimmer noch: Python schreibt sie auch standardmäßig raus. json.dumps({"a": float("nan")}) ergibt {"a": NaN}, eine Datei also, die kein JavaScript-Parser mehr lesen kann. Wer das verhindern will, muss es ausdrücklich verlangen:

json.dumps(daten, allow_nan=False)   # wirft jetzt einen Fehler statt ungültiges JSON zu schreiben

Das ist der Grund, warum eine Datei „bei mir funktioniert” und beim Empfänger nicht. Gültig ist kein absoluter Zustand, sondern eine Aussage über einen bestimmten Parser.

Die Fallen bei Zahlen, die niemand erwartet

JSON kennt genau einen Zahlentyp. Wie er umgesetzt wird, überlässt der Standard der Sprache — und JavaScript benutzt dafür Fließkommazahlen mit doppelter Genauigkeit. Das hat messbare Folgen:

JSON.parse('{"id": 9007199254740993}')
// ergibt: { id: 9007199254740992 }   ← die letzte Ziffer ist weg

Die Zahl wurde beim Einlesen stillschweigend verändert. Keine Warnung, kein Fehler. Oberhalb von Number.MAX_SAFE_INTEGER (9.007.199.254.740.991) ist jede Ganzzahl in JavaScript ein Näherungswert. Python liest dieselbe Datei dagegen exakt:

json.loads('{"id": 9007199254740993}')   # {'id': 9007199254740993}  — korrekt

Praktische Konsequenz: Datenbank-IDs, Snowflake-IDs (Discord, Twitter) und große Zähler gehören in JSON als Zeichenkette, nicht als Zahl. Genau deshalb liefert die Discord-API IDs als "1528140044693405807" in Anführungszeichen aus — das ist keine Nachlässigkeit, sondern die einzige Möglichkeit, sie unbeschädigt durch JavaScript zu bekommen.

Und die zweite Zahlenfalle, die dieselbe Ursache hat:

JSON.stringify({x: 0.1 + 0.2})   // {"x":0.30000000000000004}

Geldbeträge gehören deshalb ebenfalls nicht als Fließkommazahl in JSON. Entweder als Ganzzahl in Cent (1999) oder als Zeichenkette ("19.99").

Was JSON.stringify still verschluckt

Beim Schreiben passiert das Gegenstück: Werte, die JSON nicht kennt, verschwinden ohne Fehlermeldung. Gemessen:

JSON.stringify({
  a: undefined, b: () => 1, c: Symbol('s'),
  d: new Date(0), e: NaN, f: Infinity,
  g: new Map([[1,2]]), h: new Set([1])
})
// {"d":"1970-01-01T00:00:00.000Z","e":null,"f":null,"g":{},"h":{}}

Drei verschiedene Verhaltensweisen in einem einzigen Aufruf:

• undefined, Funktionen und Symbole fallen komplett raus — die Schlüssel a, b und c existieren in der Ausgabe nicht mehr.
• NaN und Infinity werden zu null — der Wert bleibt, seine Bedeutung nicht.
• Map und Set werden zu leeren Objekten — der Inhalt ist weg, die Struktur sieht aber intakt aus. Das ist der gefährlichste Fall, weil nichts fehlt, das jemandem auffallen würde.
• Date wird zu einer ISO-Zeichenkette. Beim Zurücklesen ist es kein Datum mehr, sondern Text. JSON.parse(JSON.stringify(x)) ist deshalb keine verlustfreie Kopie.

Nur zwei Dinge werfen tatsächlich einen Fehler: BigInt (Do not know how to serialize a BigInt) und Objekte, die auf sich selbst verweisen (Converting circular structure to JSON).

Doppelte Schlüssel: erlaubt, aber unvorhersehbar

JSON.parse('{"a":1,"a":2}')   // { a: 2 }  — der letzte gewinnt

Der Standard verbietet doppelte Namen nicht, sagt aber auch nicht, welcher gelten soll. Node und Python nehmen beide den letzten — garantiert ist das nicht. In Sicherheitszusammenhängen ist das ein bekanntes Einfallstor: Wenn ein Prüfsystem den ersten Wert liest und das Zielsystem den letzten, lässt sich eine Prüfung umgehen.

JSON, JSONC, JSON5, NDJSON: die Varianten

Weil JSON bewusst so streng ist, sind Abwandlungen entstanden. Sie sehen ähnlich aus und sind nicht austauschbar.

JSONC — JSON with Comments. Erlaubt // und /* */ sowie abschließende Kommas. Microsoft benutzt es für tsconfig.json und die VS-Code-Einstellungen. Das erzeugt eine Situation, die auf unserem eigenen Server steht: Eine Datei mit der Endung .json, die TypeScript einwandfrei liest und JSON.parse ablehnt.

$ node -e "JSON.parse(require('fs').readFileSync('touchline/tsconfig.json','utf8'))"
Expected double-quoted property name in JSON at position 129 (line 7 column 5)

An Position 129 steht ein Kommentar, der erklärt, warum eine Einstellung nötig ist. Eine sinnvolle Zeile in einer Datei, die ihre Endung nicht einhält. Merke: .json als Dateiendung ist eine Behauptung, keine Garantie.

JSON5 — geht weiter: Namen ohne Anführungszeichen, einfache Anführungszeichen, Hexadezimalzahlen, mehrzeilige Zeichenketten, Infinity und NaN. Bequem für handgeschriebene Konfiguration, braucht aber eine eigene Bibliothek. Für Datenaustausch ungeeignet.

NDJSON / JSON Lines (.ndjson, .jsonl) — ein vollständiges JSON-Objekt pro Zeile, ohne umschließendes Array und ohne Kommas dazwischen:

{"type":"connection","intensity":0.8,"timestamp":"2026-05-11T23:08:34Z"}
{"type":"curiosity","intensity":0.5,"timestamp":"2026-05-12T08:11:02Z"}

Das ist keine Spielerei, sondern das Format, in dem praktisch alle Server-Logs anfallen. Unser Caddy-Webserver schreibt jede einzelne Anfrage als eine solche Zeile; die Zugriffsdatei von getmind.io enthielt beim Schreiben dieses Artikels 34.687 Zeilen. Der Vorteil wird gleich noch quantifiziert.

JSON vs. YAML vs. TOML: wann welches Format

Alle drei speichern dieselbe Art von Daten. Die Unterschiede liegen darin, wer sie schreibt und wer sie liest.

JSON ist das Format für Datenaustausch zwischen Programmen. Seine Strenge ist dort ein Vorteil: Es gibt kaum Interpretationsspielraum, und jede Sprache bringt einen Parser mit.

YAML ist für Menschen zum Schreiben gedacht — Kubernetes, GitHub Actions, Docker Compose. Der Preis ist Mehrdeutigkeit. Die berühmteste Falle ist die „Norway-Frage”: In YAML 1.1 wird NO als Wahrheitswert false gelesen, weshalb Ländercodes ohne Anführungszeichen stillschweigend kippen. Dazu kommt, dass die Einrückung Bedeutung trägt — ein Leerzeichen zu viel ändert die Struktur, ohne einen Fehler zu werfen.

TOML liegt dazwischen. Eindeutig wie JSON, lesbar wie eine INI-Datei, mit Kommentaren. Standard bei Rusts Cargo.toml und Pythons pyproject.toml. Bei tiefer Verschachtelung wird es unübersichtlich.

Die Faustregel: Schreibt ein Mensch die Datei und liest ein Programm sie, nimm TOML oder YAML. Schreibt ein Programm und liest ein Programm, nimm JSON. Und wenn du Kommentare in einer .json brauchst, ist meistens nicht JSON falsch, sondern die Wahl des Formats.

Große JSON Dateien: was wirklich passiert

Die gängige Aussage lautet „große JSON Dateien sind langsam”. Das ist ungenau. Wir haben die größte JSON Datei auf unserem Server gemessen — eine Tokenizer-Datei eines Sprachmodells mit 32,8 MB:

readFileSync : 246 ms
JSON.parse   : 310 ms
RSS vorher   :  45 MB
RSS nachher  : 255 MB

Das Einlesen und Parsen dauert zusammen etwas über eine halbe Sekunde — das ist nicht das Problem. Das Problem ist die letzte Zeile: Aus 32,8 MB Datei werden 255 MB Arbeitsspeicher, ein Faktor von 7,8. Der Grund ist, dass jeder Schlüssel, jede Zeichenkette und jede Zahl im Speicher ein eigenes Objekt mit Verwaltungsaufwand wird. Wer eine 500-MB-Datei parsen will, braucht also nicht 500 MB frei, sondern mehrere Gigabyte.

Dazu kommt eine harte Grenze, die unabhängig vom verfügbaren RAM gilt:

require('buffer').constants.MAX_STRING_LENGTH / 1048576   // 512 (MB)

Eine Zeichenkette in Node.js kann maximal etwa 512 MB groß sein. Eine JSON Datei darüber lässt sich mit readFileSync(..., 'utf8') nicht einmal einlesen — der Fehler kommt vor dem Parser, und ein größerer Server hilft nicht.

Streamen statt laden — und wie groß der Unterschied wirklich ist

Wir haben dieselben Daten in zwei Formaten erzeugt und dieselbe Frage gestellt (wie viele Datensätze haben score > 995). Einmal als ein großes Array, einmal als NDJSON:

Bei 200.000 Datensätzen (15,9 MB):

Array, komplett geparst : 0,21 s, max RSS 110.360 KB
NDJSON, zeilenweise     : 0,26 s, max RSS  66.640 KB

Hier ist der Unterschied klein — das Streamen war sogar minimal langsamer. Wäre die Messung hier stehengeblieben, hätte man daraus „der Unterschied ist zu vernachlässigen” geschlossen. Also haben wir den Datensatz versechsfacht.

Bei 1.200.000 Datensätzen (96,7 MB):

Array, komplett geparst : 0,95 s, max RSS 371.464 KB
NDJSON, zeilenweise     : 0,89 s, max RSS  74.836 KB

Jetzt wird es deutlich: Der Speicherbedarf des Arrays ist um Faktor 3,4 gewachsen (110 MB → 371 MB), der des Streamings praktisch gar nicht (67 MB → 75 MB, und davon sind rund 45 MB der Node-Prozess selbst). Bei der Zeit gibt es keinen relevanten Unterschied.

Das ist der eigentliche Punkt, und er wird oft falsch erzählt: Streaming ist nicht schneller. Streaming ist speicherkonstant. Die Laufzeit wächst in beiden Fällen linear mit der Datenmenge, der Speicherbedarf nur bei einem von beiden. Ein Prozess, der eine Datei komplett lädt, funktioniert in der Entwicklung mit kleinen Testdaten einwandfrei und wird in der Produktion vom OOM-Killer beendet — bei derselben Codezeile.

Dasselbe gilt auf der Kommandozeile. Auf der 32,8-MB-Datei:

jq .version           : 0,77 s, max RSS 251.400 KB
jq --stream (erste 3) : 0,01 s, max RSS   3.968 KB

jq --stream liest die Datei häppchenweise, statt den ganzen Baum aufzubauen — Faktor 63 beim Speicher.

Der praktische Vorteil von NDJSON

Weil jede Zeile für sich gültig ist, lassen sich Fragen beantworten, ohne die Datei zu kennen. Auf unserer Belohnungs-Logdatei (2.006 Zeilen, 500 KB):

tail -1 datei.jsonl | jq -c '.type'   # 0,01 s, 3.968 KB RSS
jq -s '.[-1].type' datei.jsonl        # 0,02 s, 5.120 KB RSS

Bei dieser Größe ist der Unterschied bedeutungslos — bei einer Logdatei von mehreren Gigabyte ist die erste Variante die einzige, die überhaupt durchläuft. Dazu kommt der eigentliche Grund für das Format: An eine NDJSON-Datei kann man anhängen. Bei einem JSON-Array müsste man die schließende Klammer suchen, entfernen, schreiben und neu setzen — bei gleichzeitigem Zugriff geht das schief. Deshalb schreiben Log-Systeme NDJSON und keine Arrays.

Sicherheit: zwei Stellen, an denen JSON gefährlich wird

eval statt JSON.parse

In alten Anleitungen steht gelegentlich, man könne JSON mit eval() einlesen, weil es ja JavaScript-Syntax sei. Das ist technisch richtig und sicherheitstechnisch fatal: eval führt alles aus, was in der Zeichenkette steht. Ein manipulierter Server kann damit beliebigen Code im Browser des Benutzers ausführen. JSON.parse ist ein reiner Parser — er kann nichts ausführen, weil er keinen Code versteht. Es gibt keine Situation, in der eval für JSON die richtige Wahl ist.

Prototype Pollution

Diese ist subtiler, und die Verwechslung ist verbreitet. JSON.parse selbst ist nicht anfällig. Wir haben es gemessen:

const p = JSON.parse('{"__proto__":{"x":1}}');
Object.getOwnPropertyNames(p)   // [ '__proto__' ]  — normaler Schlüssel
({}).x                          // undefined        — nichts passiert

JSON.parse legt __proto__ als gewöhnlichen eigenen Schlüssel an. Gefährlich wird erst, was danach mit den Daten passiert — etwa ein selbstgebautes rekursives Zusammenführen von Konfigurationen:

function badMerge(target, source) {
  for (const k in source) {
    if (typeof source[k] === 'object' && source[k] !== null) {
      if (!target[k]) target[k] = {};
      badMerge(target[k], source[k]);
    } else target[k] = source[k];
  }
  return target;
}

badMerge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));

({}).isAdmin        // true
const user = {};
user.isAdmin        // true   ← ein frisch erzeugtes, leeres Objekt

Nach diesem einen Aufruf trägt jedes Objekt im gesamten Prozess die Eigenschaft isAdmin: true — auch alle, die erst später erzeugt werden. Eine Prüfung wie if (user.isAdmin) sagt ab jetzt für jeden Benutzer „ja”.

Der Schutz ist einfach, sobald man weiß, wo das Problem sitzt:

// 1. Schlüssel beim Parsen filtern
JSON.parse(text, (key, value) => key === '__proto__' ? undefined : value);

// 2. Ein Objekt ohne Prototyp benutzen
const safe = Object.assign(Object.create(null), JSON.parse(text));

// 3. Kein eigenes Merge schreiben, sondern strukturiertes Validieren
//    (Zod, Ajv mit JSON Schema) — dabei fallen unbekannte Schlüssel ohnehin raus

Das Muster dahinter lohnt sich zu merken: Nicht das Einlesen der Daten ist das Risiko, sondern das ungeprüfte Übernehmen ihrer Struktur. Wie sich solche Klassen von Schwachstellen einordnen lassen, haben wir in unserem Artikel über IT-Sicherheitslücken ausführlicher aufgeschrieben — inklusive eines eigenen Vorfalls, bei dem ein Einbruch fünf Tage unentdeckt blieb.

JSON prüfen und formatieren, ohne Daten hochzuladen

Bei vielen Online-Validatoren landen die eingefügten Daten auf einem fremden Server. Bei einer Beispieldatei ist das egal, bei einem Datenbank-Export oder einer Konfiguration mit Zugangsdaten nicht.

Die Alternativen, die lokal laufen:

jq empty datei.json && echo "gültig"      # prüft, gibt nichts aus, Rückgabewert zählt
python3 -m json.tool datei.json > /dev/null && echo "gültig"
node -e "JSON.parse(require('fs').readFileSync('datei.json','utf8'))" && echo "gültig"

jq empty ist die knappste Variante: Sie parst die Datei vollständig, gibt nichts aus und liefert bei einem Fehler eine Meldung mit Zeilennummer. In einem Skript oder einem Git-Hook ist das die richtige Prüfung — sie kann rot werden.

Für den Fall, dass du nur schnell etwas Strukturiertes lesbar machen willst, ohne ein Werkzeug zu installieren: Unser Markdown-Editor läuft vollständig im Browser und schickt nichts an einen Server. Dasselbe Prinzip gilt für unseren Bildkompressor — Daten, die den Rechner nicht verlassen, können auch nicht abfließen.

Häufige Fragen zu JSON Dateien

Was ist eine JSON Datei einfach erklärt?

Eine JSON Datei ist eine reine Textdatei, in der Daten strukturiert abgelegt sind — Namen mit zugehörigen Werten, beliebig tief ineinander verschachtelt. Sie enthält keine Programmlogik und keine Formatierung, nur Inhalt und Struktur. Du kannst sie mit jedem Texteditor öffnen, und praktisch jede Programmiersprache kann sie ohne Zusatzsoftware lesen.

Wie öffne ich eine JSON Datei?

Mit jedem Texteditor, auch dem vorinstallierten. Am bequemsten ist ein Code-Editor wie VS Code, weil er die Syntax einfärbt und Fehler markiert. Zum reinen Ansehen genügt es, die Datei in ein Browserfenster zu ziehen — Firefox und Chrome zeigen sie als auf- und zuklappbaren Baum an. Vermeide Textverarbeitungsprogramme wie Word: Sie ersetzen gerade Anführungszeichen automatisch durch typografische und machen die Datei damit ungültig.

Wofür wird JSON verwendet?

Vor allem für den Datenaustausch zwischen Programmen: fast jede Web-Schnittstelle antwortet in JSON. Daneben für Konfigurationsdateien (package.json, composer.json), für Server-Logs im NDJSON-Format, für den Export aus Datenbanken und für strukturierte Daten in Webseiten. JSON hat XML in den meisten dieser Rollen abgelöst, weil es kompakter und einfacher zu verarbeiten ist.

Kann man in JSON Kommentare schreiben?

Nein, der Standard sieht keine Kommentare vor — das war eine bewusste Entscheidung. Es gibt zwei übliche Auswege: die Variante JSONC (Kommentare erlaubt, benutzt von tsconfig.json und VS Code) oder ein zusätzliches Feld wie "_comment": "...", das der Parser als normalen Wert behandelt. Wenn du regelmäßig Kommentare brauchst, ist meist TOML oder YAML das passendere Format.

Was bedeutet der Fehler „Unexpected token in JSON”?

Der Parser ist auf ein Zeichen gestoßen, das an dieser Stelle nicht erlaubt ist. Die häufigsten Ursachen sind ein Komma nach dem letzten Eintrag, einfache statt doppelte Anführungszeichen, ein Schlüssel ohne Anführungszeichen oder ein unsichtbares BOM am Dateianfang. Wichtig: Die gemeldete Position zeigt oft nicht auf die Ursache, sondern auf die Stelle, an der der Fehler auffiel — suche deshalb direkt davor.

Was ist der Unterschied zwischen JSON und NDJSON?

Eine JSON Datei enthält genau ein Dokument, typischerweise ein großes Array. Eine NDJSON-Datei (auch JSON Lines) enthält pro Zeile ein vollständiges, eigenständiges JSON-Objekt. Der praktische Vorteil: Man kann anhängen, ohne die Datei zu kennen, und zeilenweise verarbeiten, ohne alles in den Speicher zu laden. In unserer Messung blieb der Speicherbedarf beim Streamen von 200.000 auf 1.200.000 Datensätze nahezu konstant, während er beim Array-Ansatz von 110 MB auf 371 MB stieg.

Warum verändert sich meine große Zahl in JSON?

Weil JavaScript alle Zahlen als Fließkommazahlen mit doppelter Genauigkeit behandelt. Oberhalb von 9.007.199.254.740.991 ist jede Ganzzahl nur noch ein Näherungswert — 9007199254740993 wird beim Einlesen stillschweigend zu 9007199254740992, ohne Fehlermeldung. Große IDs gehören in JSON deshalb als Zeichenkette in Anführungszeichen. Genau das machen Discord und Twitter mit ihren Snowflake-IDs.

Ist JSON sicher?

Das Format selbst ist harmlos — es enthält keinen ausführbaren Code, und JSON.parse kann nichts ausführen. Zwei Fehler machen es trotzdem gefährlich: JSON mit eval() einzulesen (führt beliebigen Code aus) und geparste Daten ungeprüft in eigene Objekte zu mischen (Prototype Pollution). Wir haben letzteres nachgestellt: Nach einem einzigen naiven Merge trug jedes neu erzeugte Objekt im Prozess isAdmin: true. Der Schutz ist Validierung gegen ein Schema, nicht Misstrauen gegenüber dem Format.

Warum ist meine .json Datei ungültig, obwohl sie richtig aussieht?

Drei Ursachen kommen dafür in Frage. Erstens ein unsichtbares BOM am Dateianfang, das manche Windows-Editoren anhängen — prüfbar mit file datei.json. Zweitens typografische Anführungszeichen, die eine Textverarbeitung eingesetzt hat; sie sehen fast identisch aus und sind es nicht. Drittens: Die Datei ist gar kein JSON, sondern JSONC — eine .json-Endung ist eine Behauptung, keine Garantie. Auf unserem eigenen Server liegt eine tsconfig.json, die TypeScript einwandfrei liest und JSON.parse mit einem Fehler an Position 129 ablehnt.

Fazit

Eine JSON Datei ist unspektakulär: Text, sechs Datentypen, ein paar Klammern. Der Grund, warum sie trotzdem einen ganzen Artikel füllt, liegt nicht in ihrer Komplexität, sondern in ihrer Stille.

Ein Syntaxfehler ist der freundlichste Fall, den JSON zu bieten hat — er meldet sich. Die teuren Fälle sind die anderen: Die Zahl, die beim Einlesen ihre letzte Ziffer verliert. Die Map, die als leeres Objekt geschrieben wird und deren Verschwinden niemand sieht, weil der Schlüssel ja noch da ist. Die Konfigurationsdatei, die bei dir funktioniert und beim Empfänger nicht, weil Python NaN schreibt und JavaScript es nicht lesen kann. Und das Objekt, das nach einem harmlos aussehenden Merge plötzlich in jedem anderen Objekt des Prozesses steckt.

Alle vier haben dasselbe Muster: Es gibt keine Fehlermeldung, weil formal nichts falsch ist. Das Ergebnis ist nur nicht mehr das, was jemand gemeint hat.

Die zweite Lehre aus unseren eigenen Messungen betrifft das Messen selbst. Bei 200.000 Datensätzen sah das Streamen schlechter aus als das komplette Laden — 0,26 statt 0,21 Sekunden, bei kaum geringerem Speicherbedarf. Hätten wir dort aufgehört, wäre der Artikel mit der Aussage „macht in der Praxis keinen Unterschied” fertig gewesen. Erst die Versechsfachung zeigte, was tatsächlich passiert: Der eine Wert wächst, der andere nicht. Ein Messwert, der bei einer einzigen Größe erhoben wurde, beschreibt keinen Zusammenhang — er beschreibt einen Punkt.

Wenn du danach weitermachen willst: Was ist eine .md Datei erklärt das andere Textformat, das einem ständig begegnet, TypeScript-Typisierung zeigt, wie sich JSON-Daten beim Einlesen absichern lassen, und IT-Sicherheitslücken ordnet Prototype Pollution in die größeren Angriffsklassen ein. Wer wissen will, wie die Logdateien aussehen, aus denen die NDJSON-Beispiele stammen, findet das in unserer Logfile-Analyse von KI-Crawlern. Und wenn du gerade einen Server aufsetzt, auf dem diese Dateien landen: Linux-Server einrichten ist der Startpunkt.