YAML und TOON werden beide als "lesbarer als JSON" beschrieben — und diese Beschreibung ist technisch für beide wahr, was sie nutzlos macht. Die eigentliche Frage lautet: lesbar für wen, und zu welchem Zweck? YAML ist für menschliche Bearbeitung optimiert: Kommentare, Anker, mehrzeilige Strings, Einrückung, die widerspiegelt, wie Entwickler über Konfiguration denken. TOON ist für maschinelle Verarbeitung optimiert: minimale Tokens, keine Mehrdeutigkeit, keine Syntax, die nur für menschlichen Komfort existiert. Das sind verschiedene Jobs. Sie zu verwechseln führt zu YAML in LLM-Prompts — was schlechter als JSON ist — und TOON in Kubernetes-Manifesten, die niemand manuell bearbeiten möchte. Dieser Artikel zieht die Grenze klar.

YAML in zwei Sätzen

YAML ist ein menschenfreundliches Datenserialisierungsformat, das für Konfigurationsdateien, CI/CD-Pipelines und jedes strukturierte Dokument entwickelt wurde, das ein Entwickler von Hand liest, schreibt und pflegt. Seine charakteristischen Merkmale — Inline-Kommentare, Anker/Alias DRY-Mechaniken, mehrzeilige String-Literale und einrückungsbasierte Struktur — existieren alle, um das Format für Menschen angenehm zu machen, nicht für Maschinen effizient.

Die kanonischen Anwendungsfälle sind GitHub Actions-Workflows, Kubernetes-Manifeste, Docker Compose-Dateien und Anwendungskonfigurationen, die zusammen mit dem Code ausgeliefert werden. Wenn ein Mensch erwartet wird, die Datei zu öffnen und zu bearbeiten, ist YAML eine gute Wahl. Die YAML 1.2 Spezifikation hat eine Reihe von Grenzfällen formalisiert, die YAML 1.1 plagten — am berüchtigtsten das Norwegen-Problem, bei dem der Ländercode NO in YAML 1.1-Parsern als Boolean false geparst wurde. Moderne Parser, die auf YAML 1.2 abzielen, behandeln dies korrekt, aber es ist eine nützliche Erinnerung, dass YAMLs scheinbare Einfachheit reale Parser-Komplexität verbirgt.

  • Kommentare. # dies ist ein Kommentar — YAML unterstützt Inline- und vollständige Zeilenkommentare. Allein das macht es zur richtigen Wahl für jede Konfiguration, die ein Mensch pflegen wird.
  • Anker und Aliase. Einen Block einmal mit &anchor definieren, ihn überall mit *alias wiederverwenden. Unverzichtbar für DRY Kubernetes-Konfigurationen und Multi-Environment-CI-Pipelines.
  • Mehrzeilige Strings. Literal- (|) und gefaltete (>) Block-Skalare ermöglichen das saubere Einbetten von Shell-Skripten, SQL-Abfragen oder Zertifikatsdaten in einer YAML-Datei.
  • Lesbare Einrückung. Struktur wird durch Leerzeichen definiert, was natürlich zu der Art passt, wie Entwickler über verschachtelte Konfigurationshierarchien denken.
  • Schwächen. Einrückungsempfindlichkeit bedeutet, dass ein falsch platziertes Leerzeichen ein Parse-Fehler ist. Tabulatorzeichen sind verboten. YAML 1.1-Boolescher Zwang (Norwegen-Problem, yes/no, on/off) hat echte Produktionsfehler verursacht. Tabellarische Daten als Array von Objekten ausgedrückt sind ausführlicher als sogar JSON.

TOON in zwei Sätzen

TOON ist ein kompaktes Serialisierungsformat, das für das Übergeben strukturierter Daten an und von großen Sprachmodellen entwickelt wurde, wo jedes Token Geld kostet und Kontextfensterplatz begrenzt ist. Seine zentrale Innovation ist die tabellarische Notation: für Datensätze, bei denen jeder Datensatz dieselben Felder teilt, werden Schlüssel einmal in einem Header deklariert und in jeder nachfolgenden Zeile weggelassen — was das Gegenteil von dem ist, was JSON und YAML tun.

TOON ist kein Konfigurationsformat und war es nie. Es gibt keine Kommentarsyntax. Es gibt keine Anker. Man würde einen 500-Zeilen-TOON-Datensatz nicht von Hand bearbeiten wollen, genauso wenig wie man eine Binärdatei von Hand bearbeiten würde. Was TOON bietet, ist ein Format, das dieselben Informationen wie JSON in deutlich weniger Tokens kodiert — und weniger Tokens bedeuten niedrigere API-Kosten, größere effektive Datensätze pro Prompt und weniger Druck auf Kontextfensterlimits. Der OpenAI-Tokenizer ist der schnellste Weg, dies in der Praxis zu sehen: denselben Datensatz in beiden Formaten einfügen und vergleichen.

  • Tabellarische Notation. name[count]{col1,col2,...}: gefolgt von einer Zeile Werte pro Zeile. Schlüssel erscheinen genau einmal unabhängig von der Zeilenzahl.
  • Objektnotation. {key:value,key2:value2} — keine Anführungszeichen bei Schlüsseln, kein zusätzlicher Leerraum.
  • Eindeutiges Parsing. Kein boolescher Zwang, keine Einrückungsempfindlichkeit, keine Spec-Versions-Divergenz.
  • Keine Kommentarsyntax. TOON hat keinen Mechanismus für Inline-Kommentare — by Design. Es ist ein Datenformat, kein Dokumentformat.
  • Schwächen. Nischen-Tooling, keine Bearbeitungsgeschichte für Menschen, nicht geeignet für Dateien, die ein Entwickler direkt öffnen und bearbeiten wird.

Nebeneinander: Dieselben Daten im Element jedes Formats

Der ehrlichste Vergleich zeigt jedes Format bei dem, was es wirklich gut kann — nicht einen direkten Vergleich, bei dem eines eindeutig das falsche Werkzeug ist.

Zuerst ein Kubernetes Deployment-Manifest. Das ist YAMLs Heimgebiet: eine von Menschen gepflegte Konfigurationsdatei mit Kommentaren, Ankern für gemeinsame Werte und tiefer Verschachtelung, die der logischen Hierarchie eines Kubernetes-Objekts entspricht:

yaml
# Deployment manifest for the payments-service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-service
  namespace: production
  labels:
    app: payments-service
    version: "2.4.1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payments-service
  template:
    metadata:
      labels:
        app: payments-service
    spec:
      containers:
        - name: payments-service
          image: registry.example.com/payments-service:2.4.1
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOST
              valueFrom:
                secretKeyRef:
                  name: payments-db-secret
                  key: host
            - name: LOG_LEVEL
              value: "info"
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Das in TOON zu schreiben wäre sinnlos — es sind keine tabellarischen Daten, es wird von Menschen bearbeitet, und es profitiert von Kommentaren, die nicht offensichtliche Werte erklären. YAML ist hier das richtige Werkzeug, und es gibt keinen Wettbewerb.

Jetzt dieselben Daten im Heimgebiet von TOON: ein Benutzerdatensatz, der zur Analyse an ein LLM übergeben wird. Hier erledigt TOONs tabellarische Notation die Arbeit:

text
users[12]{id,email,plan,mrr,country,signupDate,churned}:
  1001,[email protected],pro,99.00,US,2024-01-15,false
  1002,[email protected],starter,19.00,GB,2024-02-03,false
  1003,[email protected],enterprise,499.00,DE,2023-11-20,false
  1004,[email protected],pro,99.00,CA,2024-03-10,true
  1005,[email protected],starter,19.00,AU,2024-01-28,false
  1006,[email protected],pro,99.00,US,2023-12-05,false
  1007,[email protected],enterprise,499.00,FR,2024-02-14,false
  1008,[email protected],starter,19.00,IN,2024-03-22,true
  1009,[email protected],pro,99.00,US,2024-01-09,false
  1010,[email protected],enterprise,499.00,JP,2023-10-31,false
  1011,[email protected],starter,19.00,BR,2024-04-01,false
  1012,[email protected],pro,99.00,US,2024-02-19,true

Das als YAML zu schreiben — ein Array von 12 Objekten, jedes mit 7 Schlüsseln — würde alle 7 Schlüsselnamen 12 Mal wiederholen. Das sind 84 Schlüsseldeklarationen für 84 Werte. TOON deklariert jeden Schlüssel einmal.

Wo YAML TOON jedes Mal schlägt

Jede Datei, die ein Mensch öffnen, lesen und bearbeiten wird, gehört in YAML (oder JSON für einfachere Fälle). Die entscheidenden Vorteile sind Kommentare und Anker — zwei Features, die TOON einfach nicht hat.

  • CI/CD-Pipelines. GitHub Actions, GitLab CI, CircleCI — alle sind YAML-nativ. Die Möglichkeit, einen Schritt beim Debuggen auszukommentieren, ist wirklich nützlich.
  • Kubernetes und Helm. Jedes Manifest, jede Values-Datei, jede Chart-Vorlage. Das YAML-Ankersystem wird in komplexen Helm-Charts aktiv verwendet, um die Wiederholung von Umgebungskonfigurationen zu vermeiden.
  • Docker Compose. Multi-Service-Definitionen mit Kommentaren, die nicht offensichtliche Port-Bindings, Volume-Mounts und Netzwerkkonfigurationen erklären.
  • Anwendungskonfigurationsdateien. pyproject.toml-ähnliche Konfigurationen, Anwendungseinstellungen, Feature-Flags mit erklärenden Inline-Kommentaren.
  • Jede Datei in der Versionskontrolle, die Menschen in PRs überprüfen. Kommentare in YAML-Konfigurationen sind Teil der Dokumentation. TOON kann an diesem Workflow überhaupt nicht teilnehmen.
Hinweis zu Ankern: YAML-Anker (&anchor) und Aliase (*alias) werden zu wenig genutzt, sind aber leistungsstark. Eine Kubernetes-Konfiguration, die dieselben Umgebungsvariablen über mehrere Container teilt, kann sie einmal mit &common-env definieren und den Block mit *common-env referenzieren — die Datei ohne Templating-Engine DRY halten. TOON hat keinen äquivalenten Mechanismus.

Wo TOON YAML jedes Mal schlägt

Alle Daten, die programmatisch generiert und an ein LLM übergeben werden, gehören in TOON. YAML ist für diesen Anwendungsfall tatsächlich schlechter als JSON — seine einrückungslastige Syntax und wiederholten Schlüsselnamen fügen Tokens hinzu, ohne dem Modell nötige Informationen zu liefern.

  • LLM-Prompt-Payloads. Einen Datensatz an GPT-4o, Claude oder Gemini zur Analyse, Klassifizierung oder Anreicherung übergeben. TOONs tabellarische Notation reduziert die Token-Anzahl im Vergleich zu JSON um 40–60%, und im Vergleich zu YAML ist die Lücke noch größer.
  • LLM-Ausgabeanweisungen. Ein Modell anzuweisen, in TOON zu antworten, erzeugt kürzere, günstigere Ausgaben. YAML-Ausgabe von einem LLM ist ausführlich und einrückungsempfindlich — ein falsch ausgerichtetes Leerzeichen und das Parsing schlägt fehl.
  • Programmatisch generierte Datensätze. Wenn der Code die Daten aufbaut, sollte er TOON aufbauen. Es gibt keinen menschlichen Editor, der von Kommentaren oder lesbarer Einrückung profitieren würde.
  • Hochvolumige Batch-Pipelines. Täglich 10.000 Datensätze durch ein LLM verarbeiten? Eine 50%ige Token-Reduktion ist eine 50%ige Reduzierung dieser Zeile in der API-Rechnung.
  • Kontextfensterdruck. Wenn man mehr Daten innerhalb eines Kontextlimits eines Modells unterbringen muss, ermöglicht TOON mehr Zeilen zu den gleichen Token-Kosten.

Die Token-Anzahl-Realität

Hier ist derselbe 10-Zeilen-Datensatz in drei Formaten. Die Zahlen sind ungefähr, aber konsistent mit dem, was der OpenAI-Tokenizer für die Tokenisierung von GPT-4o meldet.

YAML-Array von Objekten:

yaml
- id: 1
  username: alice_chen
  plan: pro
  mrr: 99.00
  country: US
- id: 2
  username: bob_martin
  plan: starter
  mrr: 19.00
  country: GB
- id: 3
  username: carol_white
  plan: enterprise
  mrr: 499.00
  country: DE
- id: 4
  username: dan_patel
  plan: pro
  mrr: 99.00
  country: CA
- id: 5
  username: eve_torres
  plan: starter
  mrr: 19.00
  country: AU
- id: 6
  username: frank_liu
  plan: pro
  mrr: 99.00
  country: US
- id: 7
  username: grace_kim
  plan: enterprise
  mrr: 499.00
  country: FR
- id: 8
  username: henry_obi
  plan: starter
  mrr: 19.00
  country: IN
- id: 9
  username: iris_novak
  plan: pro
  mrr: 99.00
  country: US
- id: 10
  username: james_sato
  plan: enterprise
  mrr: 499.00
  country: JP

TOON-Tabellennotation, dieselben Daten:

text
users[10]{id,username,plan,mrr,country}:
  1,alice_chen,pro,99.00,US
  2,bob_martin,starter,19.00,GB
  3,carol_white,enterprise,499.00,DE
  4,dan_patel,pro,99.00,CA
  5,eve_torres,starter,19.00,AU
  6,frank_liu,pro,99.00,US
  7,grace_kim,enterprise,499.00,FR
  8,henry_obi,starter,19.00,IN
  9,iris_novak,pro,99.00,US
  10,james_sato,enterprise,499.00,JP
Ungefähre Token-Anzahlen für diesen Datensatz: YAML ≈ 290 Tokens. JSON (entsprechendes Array von Objekten) ≈ 230 Tokens. TOON ≈ 115 Tokens. YAML ist nicht nur schlechter als TOON — es ist schlechter als JSON für tabellarische Daten, weil seine Einrückungssyntax Tokens hinzufügt, die JSONs geschweifte Klammern nicht haben. TOON gewinnt mit ungefähr 2,5× über YAML und 2× über JSON bei dieser Datenform. Mit dem OpenAI-Tokenizer überprüfen.

Der Grund, warum YAML bei tabellarischen Daten schlechter als JSON abschneidet, ist strukturell: YAML verwendet eine Zeile pro Schlüssel-Wert-Paar mit Einrückung, sodass ein 5-Felder-Objekt 5 Zeilen plus den Listenmarkierer kostet. JSON verpackt das gesamte Objekt wenigstens in einen Satz geschweifter Klammern. TOON eliminiert die Schlüsselwiederholung vollständig — Schlüssel erscheinen einmal, Werte werden in Zeilen gepackt. Die Einsparungen summieren sich mit Zeilenzahl und Feldanzahl.

TOON im Code verwenden

Das @toon-format/toon-Paket übernimmt Kodierung und Dekodierung:

bash
npm install @toon-format/toon
ts
import { encode, decode } from '@toon-format/toon';

// Your dataset — could come from a database query, API response, anywhere
const users = [
  { id: 1001, email: '[email protected]', plan: 'pro',        mrr: 99.00,  country: 'US' },
  { id: 1002, email: '[email protected]',   plan: 'starter',    mrr: 19.00,  country: 'GB' },
  { id: 1003, email: '[email protected]', plan: 'enterprise', mrr: 499.00, country: 'DE' },
  // ...more rows
];

// Encode to TOON before inserting into your LLM prompt
const toonPayload = encode(users);
// users[3]{id,email,plan,mrr,country}:
//   1001,[email protected],pro,99.00,US
//   1002,[email protected],starter,19.00,GB
//   1003,[email protected],enterprise,499.00,DE

const prompt = `Analyse this user dataset and identify churn risk signals.
Return your findings as a TOON dataset with columns: id, riskScore, reason.

Dataset:
${toonPayload}`;

// After the LLM responds with TOON output, decode it back
const llmResponse = '...'; // TOON string from the model
const findings = decode(llmResponse);
console.log(findings[0]); // { id: 1001, riskScore: 'low', reason: 'Active, pro plan' }

Entscheidungshilfe

Die Wahl zwischen YAML und TOON ist in der Praxis fast nie mehrdeutig:

  • YAML verwenden, wenn ein Mensch die Datei lesen oder bearbeiten wird — CI/CD-Pipelines, Kubernetes-Manifeste, Docker Compose, Anwendungskonfigurationen, Ansible Playbooks.
  • YAML verwenden, wenn man Inline-Kommentare benötigt, um nicht offensichtliche Werte zu erklären.
  • YAML verwenden, wenn man Anker und Aliase benötigt, um eine komplexe Konfiguration DRY zu halten.
  • YAML verwenden, wenn man mit einem Tool arbeitet, das YAML per Konvention erwartet (Helm, GitHub Actions, k8s kubectl apply).
  • TOON verwenden, wenn die Daten in einen LLM-Prompt gehen — besonders tabellarische Daten mit mehreren Zeilen.
  • TOON verwenden, wenn man ein LLM bittet, strukturierte Daten zurückzugeben, und man kürzere, günstigere Ausgaben möchte.
  • TOON verwenden, wenn Token-Anzahl wichtig ist — hochvolumige Pipelines, lange Datensätze, Kontextfensterdruck.
  • TOON verwenden, wenn die Daten programmatisch generiert werden und kein Mensch sie direkt bearbeiten wird.
  • JSON (nicht YAML oder TOON) verwenden, wenn man eine REST-API aufbaut, Daten in einer Datenbank speichert oder sich mit Drittanbieter-Tooling integriert, das JSON erwartet.

Zusammenfassung

YAML und TOON nehmen völlig verschiedene Positionen im Stack ein. YAML gehört in das Repository neben dem Code — Konfigurationsdateien, Pipeline-Definitionen, Infrastruktur-Manifeste. TOON gehört an die Grenze zwischen der Anwendung und LLM-APIs, wo es strukturierte Daten in die token-effizienteste Darstellung vor dem Senden konvertiert und die Antwort des Modells auf dem Rückweg wieder zurück konvertiert. Es gibt keine bedeutende Überschneidung zwischen diesen Jobs, weshalb die Frage nicht "welches ist besser" lautet, sondern "welches gehört hierher".

Wenn man mit TOON arbeitet, sind der TOON Formatter und der TOON Validator die schnellsten Wege, TOON-Strings zu inspizieren und zu überprüfen. Der JSON-zu-TOON-Konverter konvertiert bestehende JSON-Payloads in TOON für die LLM-Verwendung, und der TOON-zu-JSON-Konverter übernimmt die Rückreise, wenn ein Modell in TOON antwortet und das nachgelagerte System JSON erwartet. Sieh auch den Wikipedia-Artikel über YAML für eine prägnante Geschichte des Formats und eine Zusammenfassung seiner bekannten Grenzfälle.

← All TOON articles Browse all categories →