Welches Format wird heute am meisten verwendet?

JSON dominiert das Web zweifellos und ist Standard bei REST APIs und Frontend Konfiguration. YAML herrscht in DevOps und Infrastruktur, vor allem in CI Pipelines und Container Definitionen. XML hält sich in Unternehmensumgebungen und in Formaten mit komplexer Dokumentstruktur. TOML hat im Ökosystem der Entwicklerwerkzeuge stark zugelegt. CSV bleibt der Standard für tabellarische Daten.

Kann ich zwischen Formaten konvertieren?

Ja, in den meisten Fällen. JSON, YAML und TOML haben ähnliche Datenmodelle und die Konvertierung zwischen ihnen ist fast direkt. XML ist wegen Attributen und gemischtem Inhalt komplexer, es gibt aber gängige Zuordnungen. CSV stellt nur Tabellen dar, weshalb die Umwandlung in hierarchische Daten oder umgekehrt Entscheidungen über das Flachklopfen der Struktur verlangt.

Warum ist YAML so fehleranfällig?

Die Spezifikation ist viel größer als sie aussieht. Manche Schlüsselwörter ("yes", "no", "on", "off") werden als Booleans interpretiert, Zahlen mit führenden Nullen können als Oktalzahlen gelesen werden, und Einrückung mit Leerzeichen oder Tabs verursacht stille Fehler. Neuere Versionen (YAML 1.2) haben einige dieser Punkte gelöst, aber du musst den strikten Modus deines Parsers im Auge behalten.

Lösen JSON5 und JSONC den fehlenden Kommentar in JSON?

Ja, das sind JSON Varianten, die Kommentare und etwas Extraflexibilität bringen (nachgestellte Kommas, Schlüssel ohne Anführungszeichen). Sie sind keine universellen Standards, werden aber in bestimmten Umgebungen wie Code Editoren unterstützt. Für den Austausch zwischen Systemen bleib bei reinem JSON, um Kompatibilität zu garantieren.

Wann sollte ich TOML statt YAML wählen?

TOML ist besser, wenn du saubere Syntax für Konfiguration ohne die Fallen der signifikanten Einrückung willst. Für Projektkonfigurationsdateien mit mittlerer Struktur ist TOML meist weniger fehleranfällig. YAML ist besser für sehr tiefe Strukturen oder wenn du interne Referenzen und fortgeschrittene Funktionen brauchst.

Datenformate im Vergleich. JSON, YAML, XML, TOML, INI, CSV

Vergleichstabelle

Format	Kommentare	Wortreichtum	Typen	Lesbarkeit	Typischer Einsatz
JSON .json	Nein	Mittel	Grundtypen	Mittel	Web APIs, Frontend Konfiguration
YAML .yaml / .yml	Ja	Gering	Grundtypen	Hoch	CI/CD Pipelines, Infrastructure as Code
XML .xml	Ja	Hoch	Nur Text	Gering	Unternehmenssysteme, Dokumente, SOAP
TOML .toml	Ja	Mittel	Reich	Hoch	Anwendungskonfiguration, Entwickler Werkzeuge
INI .ini / .conf	Ja	Gering	Nur Text	Hoch	Einfache Konfiguration, Altdateien
CSV .csv	Nein	Gering	Tabellarisch	Mittel	Tabellenkalkulationen, tabellarischer Datenexport

Format für Format

JSON.json

JavaScript Object Notation

Format, das aus der JavaScript Objektsyntax entstanden ist. Dank der Einfachheit und der nativen Unterstützung in jeder modernen Sprache wurde es zur Lingua Franca des Datenaustauschs im Web.

Beispiel

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": false,
    "tags": ["web", "api"]
  }
}

Vorteile

+Wird nativ von praktisch jeder Sprache unterstützt
+Einfache und vorhersehbare Syntax
+Schnelles und günstiges Parsing
+Klare hierarchische Struktur

Nachteile

−Keine Kommentare, was den Nutzen für handgepflegte Konfigurationsdateien einschränkt
−Wenig fehlertolerant (ein überflüssiges Komma und das Parsing scheitert)
−Wortreich bei langer Konfiguration durch erzwungene Anführungszeichen und Klammern

Wann einsetzen

Anfragen und Antworten von REST APIs, Speicherung strukturierter Daten, Kommunikation zwischen Services. Überall dort, wo Lesbarkeit zweitrangig gegenüber Interoperabilität ist.

YAML.yaml / .yml

YAML Ain't Markup Language

Format, das für menschliche Lesbarkeit gedacht ist, mit einlückungsbasierter Syntax statt Klammern. Es ist eine Obermenge von JSON.

Beispiel

server:
  host: localhost
  port: 8080
  debug: false
  tags:
    - web
    - api

Vorteile

+Sehr lesbar, ohne visuelles Rauschen durch Klammern und Anführungszeichen
+Unterstützt Kommentare und interne Referenzen
+Hervorragend für handgepflegte Dateien
+Komplexe Strukturen mit wenig Syntax

Nachteile

−Signifikante Einrückung ist eine häufige Fehlerquelle (Tabs vs Leerzeichen)
−Große Spezifikation mit überraschenden Sonderfällen ("yes" und "no" werden als Booleans interpretiert)
−Langsameres Parsing und Abhängigkeit von externen Bibliotheken in manchen Sprachen

Wann einsetzen

CI/CD Pipelines, Container Definitionen, Konfiguration von Orchestratoren und jede längere Konfigurationsdatei, die von Kommentaren und klarer Struktur profitiert.

XML.xml

Extensible Markup Language

Tag basiertes Format mit Wurzeln in SGML. Es war lange Zeit der Standard für den Austausch strukturierter Daten, bevor JSON die Oberhand gewann.

Beispiel

<server>
  <host>localhost</host>
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>web</tag>
    <tag>api</tag>
  </tags>
</server>

Vorteile

+Ausgereifte formale Schemas (XSD, DTD) für strikte Validierung
+Starke Unterstützung für Metadaten durch Attribute und Namespaces
+Mächtiges Ökosystem an Transformationen mit XSLT und Abfragen mit XPath
+Ideal für Dokumente mit gemischtem Inhalt (Text und Struktur)

Nachteile

−Sehr wortreich, öffnende und schließende Tags verdoppeln das Volumen
−Die Unterscheidung zwischen Attributen und Elementen ist willkürlich und umstritten
−Schwerer von Hand zu lesen und zu schreiben als moderne Alternativen

Wann einsetzen

Integrationen mit Alt oder Unternehmenssystemen, Dokumente mit komplexer Struktur, Formate, bei denen strenge Schemavalidierung Pflicht ist (elektronische Rechnungen, Office Dateien).

TOML.toml

Tom's Obvious Minimal Language

Relativ junges Format, das auf Eindeutigkeit ausgelegt ist. Kombiniert Abschnitte im INI Stil mit reichen Datentypen und Unterstützung für verschachtelte Strukturen.

Beispiel

[server]
host = "localhost"
port = 8080
debug = false
tags = ["web", "api"]

Vorteile

+Kurze Spezifikation ohne mehrdeutige Fälle
+Native Typen für Datumsangaben, Zahlen und Arrays
+Unterstützt Kommentare und benannte Abschnitte
+Gleichgewicht zwischen Lesbarkeit und verlässlichem Parsing

Nachteile

−Weniger universell, außerhalb der Ökosysteme, die es übernommen haben, wirkt es exotisch
−Tief verschachtelte Strukturen werden wortreicher als in YAML
−Noch wachsende Community, weniger Hilfswerkzeuge

Wann einsetzen

Konfigurationsdateien moderner Projekte, Paketmanifeste, jeder Fall, in dem du saubere Syntax ohne YAMLs Einrückungsfallen willst.

INI.ini / .conf

Initialization File

Eines der ältesten noch genutzten Formate. Strukturiert in eckigen Klammern als Abschnitte und Schlüssel Wert Paare. Es gibt keine einheitliche formale Spezifikation, was zu unverträglichen Varianten führt.

Beispiel

[server]
host = localhost
port = 8080
debug = false
tags = web,api

Vorteile

+Extrem einfach zu lesen und zu schreiben
+Trivial zu parsen, sogar mit eigenem Code
+Wird von vielen Betriebssystemen und Werkzeugen unterstützt
+Akzeptiert Kommentare und Abschnitte

Nachteile

−Kein formaler Standard, jede Implementierung weicht ab
−Keine tiefe Hierarchie über einen Abschnitt hinaus
−Alle Werte sind Strings, die Typkonvertierung liegt bei der Anwendung
−Keine native Unterstützung für strukturierte Listen

Wann einsetzen

Flache Konfiguration kleiner Werkzeuge, Benutzerdateien auf Windows und Linux Systemen, Fälle, in denen Einfachheit mehr zählt als Funktionsumfang.

CSV.csv

Comma-Separated Values

Format für tabellarische Daten: eine Zeile pro Datensatz, Werte durch Kommas getrennt. Es existiert seit Jahrzehnten und bleibt das Brot und Butter des Austauschs zwischen Tabellenkalkulationen, Datenbanken und Analysetools.

Beispiel

host,port,debug,tags
localhost,8080,false,"web,api"
example.com,443,true,"web"

Vorteile

+Universell zwischen Tabellenkalkulationen, Datenbanken und Statistikwerkzeugen
+Kompakt für rein tabellarische Daten
+Zeilenweises Streaming erlaubt riesige Dateien
+In jedem Werkzeug bearbeitbar, von Excel bis Vim

Nachteile

−Keine Hierarchie, nur eine flache Tabelle
−Keine Typen, alles ist String ohne Unterscheidung zwischen Zahl und Text
−Der Umgang mit Anführungszeichen, Kommas in Werten und Zeilenumbrüchen ist eine klassische Fehlerquelle
−Regionale Unterschiede (Komma vs Semikolon als Trennzeichen)

Wann einsetzen

Export von Berichten, Import in Tabellenkalkulationen, Datensätze für statistische Analyse, jedes Szenario, in dem die Daten wirklich tabellarisch sind.

Über dieses Werkzeug

Direkter Vergleich zwischen sechs weit verbreiteten Serialisierungsformaten: JSON, YAML, XML, TOML, INI und CSV. Für jedes Format siehst du die Syntax nebeneinander, Stärken, Schwächen und den Kontext, in dem es Sinn macht. Nützlich, um das Konfigurationsformat einer neuen Anwendung festzulegen, dich schnell in ein Format einzuarbeiten, das du nicht kennst, oder eine technische Entscheidung mit konkreten Argumenten zu untermauern.

Anleitung

Lies die Vergleichstabelle für einen Überblick über die Eigenschaften jedes Formats.
Vergleiche die Beispiele nebeneinander. Alle stellen dasselbe Objekt dar, um den Vergleich zu erleichtern.
Entscheide je nach Kontext. Manche Formate eignen sich besser für handgepflegte Konfiguration, andere besser für den Austausch zwischen Systemen.

Häufig gestellte Fragen

Welches Format wird heute am meisten verwendet?: JSON dominiert das Web zweifellos und ist Standard bei REST APIs und Frontend Konfiguration. YAML herrscht in DevOps und Infrastruktur, vor allem in CI Pipelines und Container Definitionen. XML hält sich in Unternehmensumgebungen und in Formaten mit komplexer Dokumentstruktur. TOML hat im Ökosystem der Entwicklerwerkzeuge stark zugelegt. CSV bleibt der Standard für tabellarische Daten.
Kann ich zwischen Formaten konvertieren?: Ja, in den meisten Fällen. JSON, YAML und TOML haben ähnliche Datenmodelle und die Konvertierung zwischen ihnen ist fast direkt. XML ist wegen Attributen und gemischtem Inhalt komplexer, es gibt aber gängige Zuordnungen. CSV stellt nur Tabellen dar, weshalb die Umwandlung in hierarchische Daten oder umgekehrt Entscheidungen über das Flachklopfen der Struktur verlangt.
Warum ist YAML so fehleranfällig?: Die Spezifikation ist viel größer als sie aussieht. Manche Schlüsselwörter ("yes", "no", "on", "off") werden als Booleans interpretiert, Zahlen mit führenden Nullen können als Oktalzahlen gelesen werden, und Einrückung mit Leerzeichen oder Tabs verursacht stille Fehler. Neuere Versionen (YAML 1.2) haben einige dieser Punkte gelöst, aber du musst den strikten Modus deines Parsers im Auge behalten.
Lösen JSON5 und JSONC den fehlenden Kommentar in JSON?: Ja, das sind JSON Varianten, die Kommentare und etwas Extraflexibilität bringen (nachgestellte Kommas, Schlüssel ohne Anführungszeichen). Sie sind keine universellen Standards, werden aber in bestimmten Umgebungen wie Code Editoren unterstützt. Für den Austausch zwischen Systemen bleib bei reinem JSON, um Kompatibilität zu garantieren.
Wann sollte ich TOML statt YAML wählen?: TOML ist besser, wenn du saubere Syntax für Konfiguration ohne die Fallen der signifikanten Einrückung willst. Für Projektkonfigurationsdateien mit mittlerer Struktur ist TOML meist weniger fehleranfällig. YAML ist besser für sehr tiefe Strukturen oder wenn du interne Referenzen und fortgeschrittene Funktionen brauchst.

JSON vs YAML vs XML vs TOML vs INI vs CSV

Über dieses Werkzeug

Anleitung

Häufig gestellte Fragen

Ähnliche Werkzeuge