← Alle Artikel
Aktualisiert am May 29, 20268 min read

Kaputtes JSON in JavaScript behandeln

Echtes JSON ist oft schmutzig: nachgestellte Kommas, einfache Anführungszeichen, Python-Literale, Markdown-Fences. Lerne häufige Patterns, wie man einen sicheren Parse-Helper schreibt und wann man eine dedizierte Reparatur-Library nimmt.

Jeder JavaScript-Entwickler hat es gesehen: JSON.parse() wirft einen SyntaxError, und deine Anwendung crasht. Das JSON kam aus einer API, einer Config-Datei oder dem Clipboard eines Users —— und es lässt sich einfach nicht parsen. In dieser Anleitung gehen wir genau durch, warum das passiert, wie kaputtes JSON in freier Wildbahn aussieht und wie man es elegant handhabt —— von einem einfachen try/catch bis zur automatischen Reparatur.

1. Warum JSON.parse() scheitert

Der JSON-Standard (RFC 8259) ist absichtlich strikt. JSON.parse() implementiert ihn genau —— jede Abweichung, egal wie klein, wirft einen SyntaxError ohne Teilwiederherstellung:

try {
  const data = JSON.parse('{ name: "Ada" }'); // ungequoteter Key
} catch (err) {
  console.error(err.message);
  // SyntaxError: Expected property name or '}' in JSON at position 2
}

Anders als ein Browser, der HTML parst (mit eingebautem Fehler-Recovery-Modell), ist der JSON-Parser ein hartes Gate. Strikte Parsing ist ein Feature: es zwingt Produzenten, saubere Daten auszugeben. Aber wenn du die Datenquelle nicht kontrollierst —— LLM-Output, handeditierte Config-Dateien, Drittanbieter-APIs —— brauchst du eine Strategie, wenn dieses Gate zuknallt.

2. Die häufigsten Muster kaputten JSONs

Bevor du nach einer Reparatur-Library greifst, hilft es zu erkennen, womit du es zu tun hast. Fast alles kaputte JSON in freier Wildbahn fällt in eine dieser Kategorien:

Einfache Anführungszeichen statt doppelter

// ❌ Ungültiges JSON
{ 'name': 'Ada Lovelace' }

// ✅ Gültig
{ "name": "Ada Lovelace" }

JavaScript-Object-Literals akzeptieren einfache Anführungszeichen; JSON nicht. Entwickler kopieren ein Object-Literal direkt in einen JSON-Kontext und treffen ständig auf diesen Fehler.

Trailing Commas

// ❌ Ungültiges JSON
{
  "name": "Ada",
  "active": true,   // Trailing Comma
}

// ✅ Gültig
{
  "name": "Ada",
  "active": true
}

Modernes JavaScript erlaubt Trailing Commas in Arrays und Objekten. JSON nicht. Das ist der häufigste Einzelfehler in handeditierten JSON-Dateien.

Ungequotete Objekt-Keys

// ❌ Ungültiges JSON
{ name: "Ada", score: 98 }

// ✅ Gültig
{ "name": "Ada", "score": 98 }

JavaScript-Object-Literals verlangen keine gequoteten Keys. JSON verlangt, dass alle Keys doppelt gequotete Strings sind, ohne Ausnahmen.

JavaScript-Kommentare

// ❌ Ungültiges JSON
{
  // das ist der User-Datensatz
  "name": "Ada",
  /* 2024 hinzugefügt */
  "active": true
}

JSON hat keine Kommentar-Syntax. Kommentare werden manchmal zu Config-Dateien hinzugefügt (JSONC —— JSON-with-Comments —— ist eine beliebte Erweiterung), aber JSON.parse() wird sie zurückweisen.

Mehrzeilige Strings

// ❌ Ungültiges JSON
{
  "description": "line one
  line two"
}

// ✅ Gültig —— Newline escapen
{
  "description": "line one\nline two"
}

String-Werte in JSON müssen auf einer einzigen Zeile stehen. Literale Newlines innerhalb eines Strings sind nicht erlaubt; nutze stattdessen die Escape-Sequenz \n.

NaN, Infinity und undefined

// ❌ Kein gültiges JSON
{ "ratio": NaN, "limit": Infinity, "value": undefined }

// ✅ Gültige Alternativen
{ "ratio": null, "limit": 1e308, "value": null }

Das sind gültige JavaScript-Werte, aber kein Teil der JSON-Spezifikation. JSON.stringify() konvertiert sie still (NaN und Infinity werden null; undefined-Properties werden komplett weggelassen), was subtile Round-Trip-Bugs verursachen kann.

Python-Literale

// ❌ Python-Stil —— ungültiges JSON
{ "active": True, "deleted": False, "value": None }

// ✅ Gültiges JSON
{ "active": true, "deleted": false, "value": null }

JSON wurde entworfen, um zwischen mehreren Sprachen zu interoperieren. Pythons großgeschriebene True, False und None sind eine häufige Quelle sprachübergreifender Datenbugs.

3. „Reparieren" und „Parsen" sind nicht dasselbe

Wichtig, zwischen zwei fundamental unterschiedlichen Operationen zu unterscheiden:

  • Striktes Parsen —— validieren, dass der Input exakt korrekt JSON ist, die präzise Position jedes Fehlers melden, alles Abweichende ablehnen. Nutze das, wenn du den Datenproduzenten kontrollierst und einen Vertrag durchsetzen willst.
  • Reparatur-Parsen —— versuche, einen gültigen JSON-Wert aus syntaktisch unvollkommenem Input mit heuristischen Regeln zu rekonstruieren. Nutze das, wenn die Daten aus einer nicht vertrauenswürdigen oder ungenauen Quelle kommen (LLM-Output, User-Clipboard, Legacy-Service).

Ein Reparatur-Parser macht Annahmen. Trifft er True, nimmt er an, du meintest true. Trifft er ein Trailing Comma, entfernt er es. Diese Annahmen sind für die oben gelisteten Muster fast immer korrekt —— können aber still ein echt fehlerhaftes Dokument maskieren, wo der „Fix" die beabsichtigte Bedeutung verändert.

Das richtige Werkzeug hängt vom Kontext ab. In einer schema-validierten API-Response-Pipeline willst du striktes Parsen, damit schlechte Daten sofort auftauchen. In einem Entwicklertool, wo ein Mensch JSON aus einer Slack-Nachricht einfügt, spart Reparatur-Parsen Zeit.

Wissenswerte Libraries

Zwei npm-Pakete machen den Großteil der schweren Arbeit mit komplementären Trade-offs:

  • jsonrepair —— ein toleranter Reparatur-Parser. Übergib ihm kaputtes JSON und bekomm einen Best-Effort-Gültigstring zurück. Er handhabt die obigen Muster (einfache Anführungszeichen, Trailing Commas, ungequotete Keys, Kommentare, Python-Literale, Markdown-Fences, ungeschlossene Klammern, partielles Input). Synchron, null Dependencies, klein —— ideal, wenn du ein komplettes Dokument im Speicher hast.
  • clarinet —— ein SAX-artiger Streaming-JSON-Parser. Nutze ihn, wenn das JSON in Chunks ankommt (ein Stream, eine große Datei, eine LLM-Antwort Token für Token) und du reagieren musst, sobald Keys/Werte erscheinen, statt auf das ganze Dokument zu warten. Er ist syntaktisch strikt, also kombiniere ihn mit jsonrepair, wenn die Quelle unzuverlässig ist.

Faustregel: reparieren, wenn du einen kleinen, unzuverlässigen Blob hast; streamen, wenn das Dokument groß ist oder progressiv ankommt.

4. Fehler fangen und Usern freundliches Feedback geben

Das minimal lebensfähige Muster ist ein try/catch. Tu das immer —— lass JSON.parse() nie uncaught werfen:

function safeParseJson(text) {
  try {
    return { ok: true, value: JSON.parse(text) };
  } catch (err) {
    return { ok: false, error: err.message };
  }
}

const result = safeParseJson(userInput);
if (!result.ok) {
  showError(`Could not parse JSON: ${result.error}`);
}

Die Fehlermeldung von JSON.parse() variiert je nach JavaScript-Engine. V8 (Node.js, Chrome) enthält einen Positions-Hinweis:

// V8-Fehlermeldung
"Expected ',' or '}' after property value in JSON at position 42"

// Firefox SpiderMonkey
"JSON.parse: expected ',' or '}' after property value in object
at line 3 column 5 of the JSON data"

Die Positionsinfo ist nützlich, aber engine-spezifisch. Wenn du verlässliches Zeilen-/Spalten-Reporting über Umgebungen hinweg brauchst, kann ein eigener Recursive-Descent-Parser strukturierte Fehler emittieren, die viel einfacher Usern anzuzeigen sind.

5. Wann automatisch reparieren vs. um Bestätigung bitten

Nicht alle Reparaturen tragen dasselbe Risiko. Hier eine praktische Heuristik:

  • Sicher automatisch zu reparieren —— Trailing Commas, Whitespace-Normalisierung, Anführungszeichen-Stil-Konvertierung, ungequotete Keys, JavaScript-Kommentare, Python-Boolean/Null-Literale. Mechanische Transformationen ohne semantische Mehrdeutigkeit.
  • User fragen erwägen —— strukturelle Reparaturen wie das Auto-Schließen eines ungeschlossenen Objekts oder Arrays ({"name": "Ada" → {"name": "Ada"}), oder Strippen von Inhalt (Entfernen eines absichtlich wirkenden Kommentars). Die Reparatur ist wahrscheinlich richtig, aber der User will sie vielleicht verifizieren.
  • Immer flaggen, nie still fixen —— Typkoersionen wie NaN → null ändern den Datenwert. Zeig dem User, was sich geändert hat.

Eine gute Reparatur-UI zeigt einen Diff: das ursprüngliche Input links, das reparierte Output rechts. Der User kann bestätigen, dass der Fix korrekt ist, bevor er das Ergebnis kopiert oder absendet.

6. Der Datenschutz-Vorteil von In-Browser-JSON-Verarbeitung

Wenn du JSON lokal im Browser verarbeitest —— mit der JavaScript-Engine, die die Seite ohnehin betreibt —— verlassen die Daten nie die Maschine des Users. Das zählt mehr, als Entwickler oft merken:

  • API-Keys und Credentials —— Entwickler fügen regelmäßig JSON-Payloads ein, die Secrets enthalten. Ein serverseitiges Tool loggt jede Anfrage.
  • PII und Gesundheitsdaten —— DSGVO- und HIPAA-Compliance wird viel einfacher, wenn es keinen Datentransfer gibt.
  • Unternehmensdaten —— viele Sicherheitsrichtlinien verbieten das Einfügen interner Daten in Drittanbieter-Web-Dienste.

In-Browser-Verarbeitung gibt dir Null-Risiko-JSON-Reparatur: kein Server, keine Logs, keine Datenaufbewahrung. Die Berechnung passiert in einem <textarea> und ein paar Kilobyte JavaScript.

Häufig gestellte Fragen

Wie behandle ich einen JSON.parse-Fehler in JavaScript?

Umwickele den Aufruf in try/catch und gib ein strukturiertes Ergebnis zurück, statt den SyntaxError propagieren zu lassen (siehe safeParseJson-Helper oben). Rufe JSON.parse() nie auf nicht vertrauenswürdigem Input ohne Guard auf.

Gibt es einen Weg, kaputtes JSON automatisch zu parsen?

Ja —— ein Reparatur-Parser rekonstruiert einen gültigen Wert aus unvollkommenem Input, indem er Heuristiken anwendet (Trailing Commas entfernen, einfache Anführungszeichen konvertieren, True kleinschreiben). Nutze ihn für nicht vertrauenswürdige Quellen wie LLM-Output oder eingefügten Text, nicht für vertragsvalidierte API-Antworten, wo du willst, dass schlechte Daten auftauchen.

Wann sollte ich JSON reparieren vs. ablehnen?

Reparieren, wenn ein Mensch ungefähres JSON eingefügt hat oder ein LLM es produziert hat; ablehnen (strikt parsen), wenn du den Produzenten kontrollierst und ein Schema durchsetzen willst. Typkoersionen wie NaN → null sollten immer geflaggt, nie still angewendet werden.

Was ist die häufigste Ursache für kaputtes JSON?

Ein JavaScript-Object-Literal als JSON zu behandeln —— einfache Anführungszeichen, ungequotete Keys und Trailing Commas. Siehe JSON vs. JavaScript-Objekte und die Syntaxfehler-Referenz in [object Object] und andere Fehler.

7. Probier's jetzt —— füge dein kaputtes JSON ein

Wenn du einen fehlerhaften JSON-String hast, den du sofort fixen musst, handhabt JSON Fix alle obigen Muster —— einfache Anführungszeichen, Trailing Commas, ungequotete Keys, Python-Literale, Kommentare, Markdown-Code-Fences und mehr. Alles läuft im Browser; nichts wird an einen Server gesendet.