JSONL-Formatierung

Über GeekFormat

Fügen Sie hier JSONL oder NDJSON ein. Leere Zeilen werden automatisch ignoriert, und jede Datenzeile muss ein vollständiges JSON-Objekt sein.

Das formatierte Ergebnis wird hier angezeigt.

Jede nicht leere Zeile sollte ein vollständiges JSON-Objekt sein.

Zeilen gesamt: 1Nicht leere Zeilen: 0Gültige Zeilen: 0Ungültige Zeilen: 0

JSONL einfügen, um sofort mit der Formatierung zu beginnen.

Eine schlanke JSONL-Formatierungsseite für Protokolle, Sitzungsarchive und Streaming-Exporte. Füge links die zeilenweise getrennten JSON-Objekte ein, rechts erscheint sofort das formatierte Ergebnis jeder Aufzeichnung – und du siehst direkt, welche Zeile fehlerhaft ist.

Was ist JSONL-Formatierung?

JSONL (JSON Lines) ist ein Textformat, das JSON-Aufzeichnungen zeilenweise organisiert. Sein Kernmerkmal ist nicht „sieht aus wie JSON“, sondern „jede Aufzeichnung steht allein in einer Zeile“. In der Praxis bedeutet das fast immer, dass jede nicht-leere Zeile ein vollständiges JSON-Objekt ist; die Objekte werden durch Zeilenumbrüche getrennt, statt zusätzlich in ein großes Array wie `[{...},{...}]` gepackt zu werden.

Diese Organisationsform eignet sich besonders für Protokolle, Ereignisströme, Sitzungsarchive, Massenexporte und Streaming-Verfahren. Ein Programm muss nicht erst die ganze Datei in den Speicher laden, sondern kann Aufzeichnungen zeilenweise konsumieren. Ist eine Zeile beschädigt, lässt sich direkt ihre Zeilennummer ansteuern, statt in einem überlangen JSON-Array blind Klammern zu zählen und Kommas zu suchen.

JSONL-Formatierung ist nicht dasselbe wie gewöhnliche JSON-Formatierung. Ein normaler Formatierer geht davon aus, dass die Eingabe ein einziges vollständiges JSON-Dokument ist; ein JSONL-Formatierer muss hingegen zeilenweise parsen, zeilenweise prüfen und zeilenweise Fehler melden und dabei die Semantik der zeilengetrennten Aufzeichnungen bewahren. Bei Protokollen und Exportdateien ist dieser Unterschied entscheidend.

Diese Seite ist genau um diese reale Semantik herum gebaut: Links werden zeilengetrennte Objektaufzeichnungen eingegeben, rechts erscheint das formatierte Ergebnis pro Aufzeichnung, während Fehler-, Abbruch- und Nicht-Objekt-Zeilen direkt markiert werden. Bei der Untersuchung einer `.jsonl`-Datei siehst du also „welche Aufzeichnung problematisch ist“, statt nur einen pauschalen `SyntaxError` zu erhalten.

Anwendungsfälle

JSONL aus Anwendungsprotokollen aufzeichnungsweise verschönern und dann Feld für Feld prüfen, statt auf eine lange, in eine Zeile gequetschte Objektkette zu starren
Sitzungsarchivdateien prüfen, in denen jede Zeile ein eigenes Ereignisobjekt ist, und bestätigen, dass jede Aufzeichnung vollständig und lesbar ist
Wenn eine Datenpipeline, eine Tracking-Plattform oder ein Elasticsearch-Bulk-Export fehlschlägt, schnell finden, welche Zeile des JSON-Objekts beschädigt ist
Beim Debuggen von Streaming-Schnittstellen prüfen, ob der Server wirklich fortlaufend „ein Objekt pro Zeile“ liefert und nicht ein halbes Objekt vorzeitig ausgibt
NDJSON aus dem Terminal, aus Monitoring-Dashboards oder Cloud-Protokollplattformen einfügen, zuerst strukturieren und dann weiter untersuchen
Prüfen, ob sich in KI-generierten Zeilenergebnissen irgendwo ein Array, ein String oder unvollständiges JSON eingeschlichen hat
Vor dem Import in ClickHouse, BigQuery, Kafka Connect oder andere auf Zeilendatensätze setzende Verfahren den JSONL-Inhalt zunächst manuell prüfen
Bei Audit-Protokollen, Risikoereignissen oder Tracking-Ereignisströmen aufzeichnungsweise prüfen, ob die Objektstruktur stabil und konsistent ist
Wenn eine JSONL-Datei abgeschnitten oder unvollständig heruntergeladen wurde, sofort sehen, welches Objekt am Ende nicht geschlossen wurde
Aus internen Tools exportiertes Line-Delimited JSON erst formatieren und dann zur Code-Prüfung oder zum Datenabgleich an Kollegen weitergeben
Bevor du ein Skript zum Parsen von JSONL schreibst, Feldebenen, verschachtelte Objekte und Array-Positionen manuell bestätigen, um Debug-Zeit zu sparen
Historische Exporte mit gemischten Leer- und Fehlerzeilen zuerst von Strukturproblemen säubern, bevor du entscheidest, ob eine Umwandlung in CSV oder ein Datenbankimport folgt

Anleitung

Füge den JSONL- oder NDJSON-Inhalt in den Eingabebereich ein; jede nicht-leere Zeile muss ein eigenständiges JSON-Objekt sein
Rechts wird sofort zeilenweise formatiert und bei fehlerhaften Zeilen die genaue Zeilennummer, Fehlermeldung und Originalaufzeichnung angezeigt
Korrigiere die betreffenden Zeilen anhand der Hinweise, bis die Anzahl ungültiger Zeilen null ist
Erst wenn alles gültig ist, kopiere das vollständige formatierte Ergebnis oder leite die Daten an nachgelagerte Skripte, Importer und Analyseprozesse weiter

Funktionen

JSONL / NDJSON wird Zeile für Zeile geparst, ohne dass du die Daten vorher manuell in ein komplettes JSON-Array wie `[{...},{...}]` verpacken musst
Prüfung nach der echten Dateisemantik „jede nicht-leere Zeile ist ein JSON-Objekt“, passend zu Protokollen, Ereignisströmen und Sitzungsarchiven
Geteiltes Layout: links das `textarea`-Eingabefeld, rechts sofort das formatierte Ergebnis – ideal zum parallelen Korrigieren und Prüfen
Fehlerhafte Zeilen zeigen direkt die genaue Zeilennummer, die Parsing-Fehlermeldung und den Originalinhalt, damit sich abgeschnittene Aufzeichnungen, fehlende Klammern und Verkettungsfehler schnell beheben lassen
Kopieren wird erst freigegeben, wenn alle nicht-leeren Zeilen gültig sind – so gelangen keine teils gültigen, teils beschädigten Daten in nachgelagerte Prozesse
Eingebaute Statistik zu Gesamtzeilen, nicht-leeren, gültigen und ungültigen Zeilen, um bei großen Dateien schnell zu sehen, wie viele Aufzeichnungen beschädigt sind
Beispieldaten enthalten, damit du die JSONL-Formatierung beim ersten Öffnen sofort ausprobieren kannst
Die gesamte Verarbeitung läuft lokal im Browser; Protokolle, Sitzungsereignisse und API-Exporte werden nicht hochgeladen

JSONL-Formatierung vs. JSON-Formatierung vs. JSON-Reparatur

Diese Werkzeuge werden oft nacheinander verwendet, lösen aber unterschiedliche Probleme. Den richtigen Einstieg zu wählen spart viel Zeit.

Werkzeug	Am besten geeignete Eingabe	Kernfähigkeit	Einsatzszenario
JSONL-Formatierung	Ein JSON-Objekt pro Zeile	Aufzeichnungsweise prüfen und verschönern	Protokolle, NDJSON, Sitzungsarchive, Streaming-Exporte
JSON-Formatierung	Ein vollständiges JSON-Objekt oder -Array	Gesamtes JSON-Dokument verschönern	API-Antworten, Konfigurationsdateien, einzelne Payloads
JSON-Reparatur	JSON-Text mit Syntaxfehlern oder unüblichem Aufbau	Erst Syntax reparieren, dann weiterverarbeiten	Nachgestellte Kommas, Kommentare, Anführungszeichenprobleme, abgeschnittenes JSON

Best Practices

Beim Debuggen die ursprüngliche JSONL-Form behalten, statt sie zum Verstehen manuell in ein Array zu packen

Wenn das nachgelagerte System JSONL erwartet, untersuche möglichst in der ursprünglichen „eine Aufzeichnung pro Zeile“-Form. Ein manuelles Array funktioniert zwar im normalen Formatierer, geht aber auf Kosten der ursprünglichen Zeilennummernsemantik und erschwert die Zuordnung zur echten Fehlerzeile.

Bei großen Dateien zuerst die letzten Zeilen prüfen

Viele JSONL-Dateien haben keinen Strukturfehler in der Mitte, sondern die letzten Zeilen sind durch Stromabbruch, fehlgeschlagenen Download oder unvollständiges Schreiben abgeschnitten. Zuerst auf die letzten Aufzeichnungen zu sehen ist meist schneller, als die ganze Datei von vorn durchzugehen.

Enthält die Eingabe einfache Anführungszeichen, Kommentare oder JSON5-Stil, erst die JSON-Reparatur verwenden

Die JSONL-Seite setzt auf zeilenweise Objektprüfung. Wenn die Quelldaten von Haus aus kein Standard-JSON sind, ist erst reparieren und dann formatieren meist effizienter, als jede Zeile einer langen Datei manuell zu korrigieren.

Für den erneuten Import unbedingt die Semantik „ein Objekt pro Zeile“ bewahren

Der mehrzeilige, verschönerte Block rechts ist eher für Menschen gedacht. Wenn die Daten zurück in ein Protokollsystem, eine Message-Queue oder einen Importer sollen, behalte die Ein-Objekt-pro-Zeile-Struktur der Quelldaten bei, statt die Vorschauform zum endgültigen Transportformat zu machen.

Zeilennummern als Hauptansatz nutzen, statt die ganze Datei mit den Augen durchzugehen

Beim echten Debuggen ist es meist am schnellsten, erst die Fehlerzeilennummer zu ermitteln und diesen Datensatz dann mit den benachbarten gültigen Aufzeichnungen zu vergleichen. So erkennst du schneller, ob eine Klammer oder ein Anführungszeichen fehlt, ein Feld abgeschnitten ist oder ein Objekt den falschen Typ enthält.

Häufig gestellte Fragen

Was ist der Unterschied zwischen JSON und JSONL?

Gewöhnliches JSON ist meist ein ganzes Objekt oder Array, das als ein einziges vollständiges Dokument geparst wird. JSONL (JSON Lines, oft auch NDJSON genannt) enthält dagegen eine unabhängige Aufzeichnung pro Zeile – im Ingenieuralltag am häufigsten „ein JSON-Objekt pro Zeile“. Es eignet sich besser für Protokolle, Ereignisströme, Streaming-Verfahren und Massenimporte, da sich zeilenweise lesen, schreiben und Fehler lokalisieren lässt.

Warum betont diese Seite „ein JSON-Objekt pro Zeile“?

Weil die meisten echten JSONL-Dateien so aufgebaut sind, besonders Protokolle, Sitzungsarchive, Ereignisströme und Exportdateien. Deine Archivbeispiele folgen ebenfalls diesem typischen Muster: Jede Zeile ist ein durch einen Zeilenumbruch getrenntes Objekt. Die Seite prüft nach dieser Semantik, was zum echten Debug-Alltag besser passt als die beliebige Akzeptanz jedes JSON-Werts.

Worin unterscheidet sich JSONL von einem JSON-Array wie `[{...},{...}]`?

Ein JSON-Array ist ein vollständiges JSON-Dokument, das erst komplett gelesen und dann geparst werden muss. JSONL zerlegt jede Aufzeichnung in eine eigene Zeile, lässt sich streaming-fähig lesen und erlaubt es, bei einem Fehler direkt die betroffene Zeile zu finden. Für große Protokolldateien und Ereignisströme ist JSONL deshalb besser geeignet als ein einziges großes Array.

Warum werden Leerzeilen ignoriert?

Leerzeilen entstehen meist durch Kopieren und Einfügen, Protokollrotation oder manuelle Bearbeitung und stellen keine echten Datensätze dar. Werden sie ignoriert, reduziert das Rauschen, während alle inhaltlich gefüllten Zeilen weiterhin streng geprüft werden.

Was passiert, wenn eine Zeile ein Array, ein String oder `null` ist?

Diese Seite stuft sie als ungültige Zeile ein, denn das Zielformat lautet „jede nicht-leere Zeile ist ein JSON-Objekt“. Wenn deine Daten tatsächlich Arrays oder Rohwerte zeilenweise speichern müssen, handelt es sich nicht um das typische JSONL-Protokollszenario, auf das diese Seite optimiert ist.

Warum lässt sich bei einer einzigen fehlerhaften Zeile nicht das gesamte Ergebnis kopieren?

Das ist eine bewusst konservative Interaktion. Kopieren ist nur erlaubt, wenn alle nicht-leeren Zeilen gültig sind, damit kein teils erfolgreiches, teils beschädigtes Ergebnis an nachgelagerte Importer, Skripte oder Kollegen weitergegeben wird – das erspart die zweite Fehlersuche.

Hilft es mir, abgeschnittene Protokolldateien zu erkennen?

Ja. Viele JSONL-Probleme entstehen in den letzten Zeilen, etwa wenn bei einem Objekt das `}` fehlt, einer Zeichenkette das schließende Anführungszeichen oder der Netzwerkstrom mittendrin abbricht. Die Seite zeigt die betreffende Fehlerzeile direkt an, besonders hilfreich bei unvollständigen Downloads und abgebrochenen Streaming-Ausgaben.

Sind JSONL und NDJSON dasselbe?

In den meisten Ingenieurkontexten lassen sie sich als Synonyme verwenden. Beide bezeichnen durch Zeilenumbrüche getrennte JSON-Aufzeichnungen, es handelt sich nur um unterschiedliche Namensgewohnheiten.

Werden meine Daten beim Formatieren von JSONL hochgeladen?

Nein. Sämtliches Parsen, Prüfen und Formatieren läuft ausschließlich lokal im Browser ab; Protokolle, API-Antworten, Sitzungsarchive und Datenexporte werden nicht an einen Server gesendet.

Wann sollte man eher die gewöhnliche JSON-Formatierung statt der JSONL-Formatierung verwenden?

Wenn deine Eingabe selbst ein vollständiges JSON-Objekt oder ein Array ist, etwa ein API-Antwortkörper, eine Konfigurationsdatei oder ein Datenpaket wie `[{...},{...}]`, gehört sie in die gewöhnliche JSON-Formatierungsseite. Nur wenn die Eingabe aus durch Zeilenumbrüche getrennten Einzelobjekten besteht, ist diese JSONL-Seite die bessere Wahl.

Glossar

JSONL: Ein Textformat mit zeilenweise getrennten JSON-Aufzeichnungen. Die gebräuchlichste Schreibweise im Ingenieuralltag: Jede nicht-leere Zeile ist ein vollständiges JSON-Objekt.
JSON Lines: Die ausgeschriebene Bezeichnung und ein weiterer gebräuchlicher Name für JSONL, meist synonym verwendet.
NDJSON: Abkürzung für „Newline Delimited JSON“, also zeilenumbruchgetrenntes JSON. In den meisten Protokoll- und Datenpipeline-Szenarien praktisch gleichbedeutend mit JSONL.
Zeilenweise Aufzeichnung: Ein Datenlayout, bei dem jede Zeile eine vollständige Aufzeichnung darstellt; geeignet für streaming-fähiges Schreiben und Lesen sowie das zeilengenaue Lokalisieren von Fehlern.
Pretty Print / lesbare Formatierung: Komprimiertes einzeiliges JSON in eine lesbare Struktur mit Einrückungen und Zeilenumbrüchen bringen, damit sich Feldebenen besser manuell prüfen lassen.
Fehlerzeile: Eine Zeile, die kein gültiges JSON ist oder sich zwar parsen lässt, aber nicht der erwarteten Struktur entspricht (z. B. kein Objekt ist) und daher keine gültige JSONL-Aufzeichnung darstellt.
Abgeschnittener Strom: Ein Protokoll oder Export, der während Übertragung, Puffer-Flush oder Speichern mittendrin abgebrochen wurde, sodass die letzte Aufzeichnung nicht vollständig geschlossen ist.
JSON-Array: Eine komplette, in Standard-JSON von `[` und `]` umschlossene Sammlung, etwa `[{...},{...}]`. Anders als JSONL muss sie als ein einziges Gesamtdokument geparst werden.

Authoritative References

jsonlines.orgOffizielle JSON-Lines-Beschreibung
IETFJSON-Offizielle Spezifikation RFC 8259