JSON, JSONL und TOON: Welches Datenformat zu welchem Engpass passt

Seit Jahren ist JSON die Standardmethode, strukturierte Daten aufzuschreiben. REST-APIs, Konfigurationsdateien, Datenbanken, Browser-Apps und der Verkehr zwischen Services stützen sich darauf. Doch die Art, wie Software mit Daten umgeht, verändert sich ständig. Datensätze sind riesig, Ereignisse kommen als Streams an, und große Sprachmodelle nehmen inzwischen strukturierte Daten als Eingabe.

Deshalb rücken zwei weitere Formate in den Blick: JSONL und TOON. Auf den ersten Blick wirken sie wie Konkurrenten von JSON, doch jedes beantwortet eine andere Frage. JSON ist für den Austausch strukturierter Daten gebaut. JSONL dafür, unabhängige Datensätze effizient abzuarbeiten. TOON dafür, Daten in JSON-Form kleiner und token-günstiger zu machen, wenn sie an ein LLM gehen. Die Frage, welches „besser“ ist, geht am Kern vorbei. Hilfreicher ist zu verstehen, wofür jedes da ist.

JSON: die universelle Basis

JSON, kurz für JavaScript Object Notation, stellt Daten mit Objekten, Arrays, Strings, Zahlen, Booleans und null dar. Seine größte Stärke ist nicht die Syntax, sondern das Ökosystem drumherum: Fast jede Programmiersprache bringt eine JSON-Bibliothek mit, und Webplattformen unterstützen es nativ.

Ein typischer Datensatz sieht so aus:

{
  "users": [
    {
      "id": 1,
      "name": "Alice",
      "role": "admin"
    },
    {
      "id": 2,
      "name": "Bob",
      "role": "user"
    }
  ]
}

Diese Form passt zu einer App, die strukturierte Informationen weitergeben muss. Darum eignet sich JSON für REST-APIs, Konfiguration, Anwendungsdaten und alle Fälle, in denen die gesamte Struktur überschaubar groß ist.

Schwierig wird es, wenn dieselbe Form auf sehr große Datensätze ausgedehnt wird oder ein LLM Tausende ähnlicher Objekte lesen muss.

JSONL: ein Datensatz pro Zeile

JSONL steht für JSON Lines. Statt alle Datensätze in ein großes Array zu packen, schreibt es in jede Zeile ein vollständiges JSON-Objekt. Dieselben Nutzer ließen sich so speichern:

{"id":1,"name":"Alice","role":"admin"}
{"id":2,"name":"Bob","role":"user"}
{"id":3,"name":"Carol","role":"user"}

Jede Zeile ist ein eigenständiger Datensatz. Das wirkt wie eine kleine Syntaxänderung, verändert aber, wie sich die Daten verarbeiten lassen. Ein großes JSON-Array kann ein Programm zwingen, die gesamte Struktur zu parsen, bevor es auch nur einen Datensatz anfasst. Mit JSONL liest ein Programm eine Zeile, parst sie, verarbeitet sie und geht zur nächsten.

Am meisten lohnt sich das bei Logdateien, Event-Streams, ML-Trainingsdaten, ETL-Jobs und allen anderen Daten, die groß sind oder ständig wachsen. Nehmen wir einen Datensatz von 50 GB. Ihn komplett als ein riesiges Objekt zu laden, will man selten. Mit JSONL lassen sich Datensätze schrittweise verarbeiten, und der Speicher geht vor allem an die Datensätze, die gerade in Arbeit sind.

JSONL beantwortet also ein Problem der Datenverarbeitung.

TOON: weniger Tokens für das Modell

Stellen Sie sich nun ein anderes Problem vor: Tausende strukturierte Datensätze sollen an ein LLM gehen. JSON funktioniert, schleppt aber viel Interpunktion und wiederholte Namen mit:

{
  "users": [
    {"id": 1, "name": "Alice", "role": "admin"},
    {"id": 2, "name": "Bob", "role": "user"},
    {"id": 3, "name": "Carol", "role": "user"}
  ]
}

Sehen Sie, wie sich "id", "name" und "role" in jedem Objekt wiederholen. Herkömmlicher Software ist das ziemlich egal. Für ein LLM erhöhen all diese Zeichen jedoch die Zahl der Input-Tokens.

Genau diese Lücke füllt TOON, die Token-Oriented Object Notation. Es ist eine kompakte, menschenlesbare Kodierung des JSON-Datenmodells, gedacht vor allem für Prompts und andere Kontexte, in denen der Token-Verbrauch zählt. Dieselben Datensätze sehen dann so aus:

users[3]{id,name,role}:
  1,Alice,admin
  2,Bob,user
  3,Carol,user

Feldnamen werden einmal deklariert, danach folgen die Datensätze als Zeilen. Das Prinzip ist einfach: Dem Modell nicht immer wieder dieselbe Struktur erklären, sondern sie einmal nennen und die Werte liefern.

Die Frage, die jedes Format stellt

Eine Möglichkeit, die drei auseinanderzuhalten, ist der Blick darauf, was jedes lösen will.

• JSON fragt, wie sich strukturierte Daten in einem Format darstellen lassen, das alle unterstützen.
• JSONL fragt, wie sich viele unabhängige Datensätze so darstellen lassen, dass man sie Stück für Stück verarbeiten kann.
• TOON fragt, wie sich Daten in JSON-Form kompakter schreiben lassen, wenn sie an ein LLM gehen.

Darum sind JSONL und TOON kein Ersatz füreinander. JSONL ändert, wie Datensätze organisiert sind. TOON ändert, wie strukturierte Daten dargestellt werden, um Tokens zu sparen. JSON bleibt in vielen dieser Abläufe darunter das Allzweckformat.

Szenario eins: eine stark ausgelastete Log-Pipeline

Nehmen wir ein großes Log-Verarbeitungssystem, in dem jede Sekunde Tausende Ereignisse auftauchen:

User logged in
Payment completed
Order created
Email sent

Werden diese Ereignisse als einzelne JSON-Objekte gespeichert, eines pro Zeile, kann ein Consumer sie verarbeiten, sobald sie eintreffen. Hier spielt JSONL seine Stärke aus. Es passt zu Daten, die groß sind, nur angehängt werden, laufend entstehen oder von Natur aus aus Datensätzen bestehen. Logs, Event-Streams, ML-Pipelines, ETL-Systeme und Big-Data-Verarbeitung sind sein übliches Zuhause.

JSON bleibt die natürlichere Wahl, wenn die gesamte Struktur ein logisches Dokument ist oder Anwendungen gewöhnliche JSON-APIs erwarten.

Szenario zwei: ein Agent liest 10.000 Kunden

Jetzt braucht ein KI-Agent Informationen über 10.000 Kunden. Als JSON-artige Datensätze verschickt, wiederholt jede Zeile ihre Schlüssel:

{"id":1,"name":"Alice","city":"Delhi"}
{"id":2,"name":"Bob","city":"Mumbai"}
{"id":3,"name":"Carol","city":"Pune"}

TOON kann eine gleichförmige Sammlung als Tabelle darstellen und die Feldnamen nur einmal angeben:

customers[3]{id,name,city}:
  1,Alice,Delhi
  2,Bob,Mumbai
  3,Carol,Pune

Daher kommt die Token-Ersparnis. Laut Spezifikation ist TOON eine einrückungsbasierte, zeilenweise Kodierung desselben Datenmodells, das JSON verwendet, und jedes Array gibt seine Länge und seine Feldliste nur einmal an.

Das Projekt berichtet außerdem von Benchmarks, in denen TOON auf seinen Testdatensätzen deutlich weniger Tokens brauchte als formatiertes JSON. Wie viel Sie sparen, hängt allerdings von der Form der Daten und vom Tokenizer ab. TOON ist nicht automatisch für jeden Datensatz besser. Am meisten gewinnt es bei gleichförmigen Arrays von Objekten mit wiederkehrenden Feldern.

Wird TOON JSON ersetzen?

Das zu behaupten ist verlockend und zu einfach. Die Spezifikation selbst stellt TOON vor allem als Darstellung für Daten in JSON-Form vor. Sie sagt, TOON solle JSON weder in Allzweck-APIs ersetzen noch in Fällen mit tiefer Verschachtelung oder ungleichförmigen Strukturen.

Ein realistischer Ablauf behält JSON dort, wo es schon funktioniert, und setzt TOON nur an der Grenze zum Modell ein:

Application data
      ↓
    JSON
      ↓
Convert for LLM
      ↓
    TOON
      ↓
     LLM

JSON bleibt die native Darstellung der Anwendung, und TOON wird zum Format, in dem strukturierte Daten ins LLM gehen. In dieser Rolle ähnelt TOON eher einer Übersetzungsschicht als einem universellen Ersatz.

Gemeinsam einsetzen

Die Formate können sich auch eine Architektur teilen. Bei JSONL geht es darum, wie Datensätze organisiert und verarbeitet werden. Bei TOON darum, wie strukturierte Daten effizient für ein LLM dargestellt werden. Eine Anwendung könnte einen großen Strom von Datensätzen als JSONL erzeugen, sie schrittweise verarbeiten, die relevante Teilmenge herausfiltern und diese dann als TOON kodieren, bevor sie an ein Modell geht.

Jedes Format beseitigt einen anderen Engpass. JSONL hilft bei der Verarbeitung von Datensätzen im großen Maßstab, TOON bei der Token-Effizienz und JSON bei der allgemeinen Interoperabilität.

Die Wahl treffen

Greifen Sie zu JSON, wenn Sie eine breit unterstützte, universelle Art suchen, strukturierte Daten zu halten. Öffentliche APIs, Browser-Apps, Konfigurationsdateien und Datensätze moderater Größe sind die offensichtlichen Fälle. Kaum ein Format kommt an sein Tooling heran, und ein kleiner, gewöhnlicher Datensatz liefert keinen Grund, etwas anderes einzuführen.

Erwägen Sie JSONL, wenn die Daten ein Haufen unabhängiger Datensätze sind, die Sie schrittweise verarbeiten wollen. Logs, Event-Streams, ML-Trainingsdaten, ETL-Pipelines und große Datensätze sind gute Beispiele. Die entscheidende Frage ist, ob der ganze Datensatz als eine Struktur behandelt werden muss oder ob ein Datensatz nach dem anderen genügt. Wenn Letzteres, lohnt sich ein Blick auf JSONL.

Erwägen Sie TOON, wenn der Empfänger ein LLM ist und die Daten viele wiederholte, strukturierte Datensätze enthalten. Es passt zu gleichförmigen Arrays, in denen dieselben Felder in vielen Objekten wiederkehren, was die Spezifikation als seinen Sweet Spot nennt. Tief verschachtelte oder sehr unregelmäßige Daten sind als JSON womöglich einfacher oder sogar kleiner. Fragen Sie sich, ob Tokens dafür verschwendet werden, immer wieder dieselbe Struktur zu beschreiben. Falls ja, verdient TOON eine Prüfung.

Unterschiedlicher Druck, unterschiedliche Formate

JSON verschwindet nicht. Vielmehr bringen unterschiedliche Datenprobleme spezialisierte Formate hervor. JSON hat gewonnen, weil Software einen einfachen, interoperablen Weg brauchte, strukturierte Daten zu beschreiben. JSONL entstand aus dem Bedarf, mit unabhängigen Datensätzen zu arbeiten, besonders als Datensätze größer wurden oder ohne Pause eintrafen. TOON kommt aus einem anderen Druck: LLMs arbeiten in Tokens, und strukturelle Syntax immer wieder mitzuschicken, kostet etwas.

Das richtige Denkmodell ist also keine Kette, an deren Ende JSON tot ist. Es lautet: JSON für universelle Struktur, JSONL für Datensatzverarbeitung im großen Maßstab, TOON für token-effiziente LLM-Eingaben. Kein einzelnes Format dürfte alle anderen ersetzen. Klüger ist es, die Darstellung zu wählen, die zu dem Engpass passt, den Sie tatsächlich haben.