INI, YAML oder JSON: das richtige Format für Konfiguration und Datenaustausch

Drei Formate im Kurzporträt

INI, YAML und JSON sind die drei meistgenutzten Textformate für Konfiguration und Datenaustausch. Sie überschneiden sich, sind aber für unterschiedliche Zwecke gebaut. Ein kurzer Steckbrief vorab.

INI: das einfache Konfigurationsformat

INI stammt aus der frühen Windows-Welt und ist das schlankeste der drei. Es kennt Sektionen in eckigen Klammern und darunter Schlüssel-Wert-Paare als key=value. Kommentare beginnen mit ; oder #. INI ist flach, leicht zu lesen und zu bearbeiten, aber kein streng standardisiertes Format, es gibt viele Dialekte. Mehr dazu im Ratgeber Was ist eine INI-Datei?.

YAML: lesbar und mächtig

YAML (kurz für YAML Ain't Markup Language) ist auf maximale Lesbarkeit ausgelegt. Statt Klammern nutzt es Einrückung, um Struktur auszudrücken. Es unterstützt tiefe Verschachtelung, Listen, Datentypen und Kommentare. Diese Mächtigkeit hat einen Preis: YAML ist empfindlich bei der Einrückung und kennt einige überraschende Sonderfälle. Es ist heute das Standardformat für Docker Compose, Kubernetes und viele CI-Pipelines.

JSON: streng und maschinenfreundlich

JSON ist der Standard für den Datenaustausch zwischen Programmen. Es kennt echte Datentypen, verschachtelt beliebig tief und ist streng definiert, sodass jeder Parser es gleich versteht. Es verbietet allerdings Kommentare und ist beim Bearbeiten von Hand fehleranfälliger. Die Grundlagen erklärt der Ratgeber Was ist JSON?.

Das gleiche Beispiel in allen drei Formaten

Am schnellsten versteht man die Unterschiede an derselben Konfiguration. Hier eine App mit Datenbank-Einstellung und einer Liste erlaubter Hosts, zuerst als INI:

; app.ini
name=Shop
debug=true

[datenbank]
host=localhost
port=5432

[hosts]
erlaubt[]=app.de
erlaubt[]=api.app.de

Dieselbe Information als YAML, mit Einrückung statt Klammern und einer nativen Liste:

# app.yaml
name: Shop
debug: true
datenbank:
  host: localhost
  port: 5432
hosts:
  erlaubt:
    - app.de
    - api.app.de

Und schließlich als JSON, streng und ohne Kommentar:

{
  "name": "Shop",
  "debug": true,
  "datenbank": {
    "host": "localhost",
    "port": 5432
  },
  "hosts": {
    "erlaubt": ["app.de", "api.app.de"]
  }
}

Alle drei sagen dasselbe aus. INI ist am kompaktesten, braucht für die Liste aber die etwas behelfsmäßige []-Schreibweise. YAML liest sich fast wie ein Notizzettel und bildet die Liste elegant ab. JSON ist am strengsten und am eindeutigsten für Maschinen, kann aber den Kommentar nicht behalten.

Der Vergleich in der Tabelle

Diese Übersicht stellt die drei Formate direkt gegenüber:

Verschachtelung und Struktur

Der größte strukturelle Unterschied liegt in der Tiefe. INI ist im Kern zweistufig: oberste Ebene und Sektionen. Echte Hierarchie bildet es nur über die Konvention der Punkt-Sektionen wie [server.datenbank] ab, was bei mehreren Ebenen schnell unübersichtlich wird. YAML und JSON sind dagegen beide baumartig und können beliebig tief verschachteln.

YAML drückt diese Tiefe durch Einrückung aus, JSON durch Klammern. Beides hat Vor- und Nachteile: YAML wirkt aufgeräumter, weil es keine Klammern und kaum Anführungszeichen braucht, ist dafür aber empfindlich. Eine falsche Anzahl Leerzeichen oder ein Tabulator statt Leerzeichen verändert die Bedeutung oder bricht das Parsen. JSON ist hier robuster, weil die Struktur durch Klammern eindeutig festgelegt ist und Einrückung nur der Optik dient.

Kommentare und Datentypen

Bei Kommentaren teilt sich das Feld klar: INI und YAML erlauben Kommentare, JSON nicht. Für Konfiguration, die ein Mensch pflegt und versteht, ist das ein gewichtiges Argument gegen JSON. Wer in JSON Erklärungen unterbringen will, muss zu eigenen Feldern oder den Varianten JSONC und JSON5 greifen.

Bei den Datentypen sind YAML und JSON typisiert, INI nicht. In INI ist port=5432 zunächst nur Text. In YAML und JSON ist 5432 eine echte Zahl und true ein echter Wahrheitswert. YAML treibt das sogar weiter und erkennt mehr Schreibweisen, was gelegentlich überrascht: Das berüchtigte Beispiel ist no, das ältere YAML-Parser als Boolean false deuten, obwohl der Ländercode für Norwegen gemeint war. JSON ist hier vorhersehbarer, weil es weniger Sonderfälle kennt.

Für den Weg von INI nach JSON bedeutet das eine bewusste Entscheidung über die Typ-Heuristik, die unser Konverter abschaltbar anbietet. Die Details stehen im Ratgeber INI-Datentypen in JSON.

Konfiguration gegen Datenaustausch

Die wichtigste Leitfrage bei der Wahl ist: Lesen vor allem Menschen die Datei oder vor allem Maschinen?

Für Konfiguration durch Menschen sind INI und YAML im Vorteil, weil sie Kommentare erlauben und angenehm zu bearbeiten sind. INI passt zu einfachen, flachen Einstellungen, YAML zu komplexer, verschachtelter Konfiguration. Genau deshalb haben sich Docker Compose, Kubernetes und viele CI-Systeme für YAML entschieden, ihre Konfigurationen sind tief verschachtelt und werden von Hand gepflegt.

Für Datenaustausch zwischen Programmen ist JSON nahezu konkurrenzlos. Es ist streng, kompakt, in jeder Sprache nativ mit einem Funktionsaufruf zu lesen und zu schreiben und es kennt keine überraschenden Sonderfälle. Web-APIs liefern ihre Antworten praktisch immer als JSON. YAML wird für reinen Austausch selten genutzt, weil seine Mächtigkeit und Sonderfälle dort eher Risiko als Nutzen sind.

Entscheidungshilfe nach Anwendungsfall

Diese Faustregeln führen schnell zur passenden Wahl:

• Einfache, flache Einstellungen, von Hand gepflegt: INI. Beispiel: eine Anwendungs-Konfiguration mit ein paar Sektionen, git config, php.ini.
• Komplexe, verschachtelte Konfiguration mit Kommentaren: YAML. Beispiel: Docker Compose, Kubernetes-Manifeste, CI-Pipelines.
• Datenaustausch zwischen Programmen oder über eine API: JSON. Beispiel: REST-API-Antworten, package.json, Logdaten.
• Maximale Robustheit und Eindeutigkeit, maschinell erzeugt: JSON, weil es keine Einrückungsfallen und kaum Sonderfälle hat.
• Schnelle, von Menschen verständliche Liste ohne viel Syntax: YAML, dank seiner eleganten Listen-Schreibweise.

Wenn die Entscheidung nur zwischen INI und JSON steht, hilft der fokussierte Vergleich INI oder JSON? weiter.

Migrationswege zwischen den Formaten

Weil alle drei Formate dieselben Grundstrukturen abbilden, lassen sie sich ineinander überführen. In der Praxis ist JSON die Drehscheibe: Fast jedes Werkzeug kann von und nach JSON wandeln, und JSON ist das eindeutigste Zwischenformat. Ein typischer Weg sieht so aus:

1. INI nach JSON umwandeln, etwa um eine alte Konfiguration in ein modernes System zu übernehmen.
2. JSON bei Bedarf nach YAML überführen, wenn die Zielanwendung YAML erwartet.
3. Oder JSON zurück nach INI, wenn ein schlankes, kommentierbares Format gewünscht ist.

Bei jeder Migration gelten zwei ehrliche Einschränkungen. Erstens: Sobald JSON im Spiel ist, gehen Kommentare verloren, weil JSON sie nicht kennt. Der Inhalt bleibt gleichwertig, die Erklärungen sind danach weg. Zweitens: INI ist flach, sehr tief verschachteltes YAML oder JSON passt deshalb nicht immer sauber in INI. In solchen Fällen meldet ein guter Konverter das klar, statt etwas Falsches zu erzeugen.

Für die beiden häufigsten Wege rund um INI und JSON gibt es unseren INI-zu-JSON- und JSON-zu-INI-Konverter. Er arbeitet zu 100 Prozent lokal in deinem Browser, ohne Upload und ohne Anmeldung, was gerade bei Konfigurationsdateien mit Passwörtern wichtig ist. Die Schritt-für-Schritt-Anleitungen findest du in den Ratgebern INI in JSON umwandeln und JSON in INI umwandeln.

Häufige Fragen