JSON vs YAML vs CSV - Welches Datenformat wann nutzen

JSON, YAML und CSV speichern alle strukturierte Daten, sind aber nicht austauschbar. Derselbe Personendatensatz sieht in allen dreien ordentlich aus - bis Sie verschachtelte Adressen, typisierte Booleans, Kommentare in der Config oder eine Tabelle brauchen, die Ihr Team in Excel oeffnen kann. Waehlen Sie das falsche Format, verlieren Sie Typen, flachen Sie Baeume in unhandliche Spalten ab oder treffen auf Parser-Ueberraschungen wie YAML, das den Laendercode NO in false verwandelt. Dieser Guide stellt JSON vs YAML vs CSV nebeneinander, zeigt wann welches Format gewinnt, und verlinkt die kostenlosen Konverter auf ToolsMinify.

Derselbe Datensatz in allen drei Formaten

Starten Sie mit einem Objekt: eine id, ein name, ein active-Flag und tags. So sieht der Datensatz in jedem Format aus, damit Sie die Syntax auf einen Blick vergleichen koennen.

JSON

• {"id": 42, "name": "Ada", "active": true, "tags": ["admin", "beta"]}
• Keys in Anfuehrungszeichen, Kommas zwischen Feldern, eckige Klammern fuer Arrays, true/false/null als Literale.
• Keine Kommentare. Trailing Commas sind in Standard-JSON ungueltig.

YAML

• id: 42
• name: Ada
• active: true
• tags:
• - admin
• - beta
• Einrueckung definiert die Struktur. Anfuehrungszeichen sind oft optional. Kommentare beginnen mit #.

CSV

• id,name,active,tags
• 42,Ada,true,"admin;beta"
• Eine Header-Zeile, dann eine Zeile pro Datensatz. Verschachtelte Arrays werden zu einem geflachten String oder Extra-Spalten. Keine nativen Typen ausser Text.

Sie haben schon ein JSON-Array von Objekten? Fuegen Sie es in den JSON to CSV Converter ein, um eine tabellenfreundliche CSV zu erzeugen. Config in die andere Richtung? Nutzen Sie den YAML to JSON Converter, bevor ein API-Client nur JSON spricht.

JSON: der API- und Austausch-Standard

JSON (JavaScript Object Notation) ist eine Teilmenge der JavaScript-Objektsyntax, die jede gaengige Sprache parsen kann. Objekte, Arrays, Strings, Zahlen, Booleans und null sind first-class. Verschachtelung ist unbegrenzt, daher ist ein address-Objekt innerhalb eines user-Objekts natuerlich. Deshalb liefern REST- und GraphQL-Antworten, Webhook-Bodies und viele Config-Stores JSON.

• Am besten fuer: API-Request- und -Response-Bodies, Browser- und Mobile-Clients, Message Queues, alles, was durch viele Sprachen round-trippen muss.
• Staerken: strikte Grammatik, vorhersagbare Typen, exzellentes Tooling, einfach zu minifizieren und zu pretty-printen.
• Grenzen: keine Kommentare, keine mehrzeiligen Strings ohne Escaping, keine Anker oder Merges. Menschen, die grosses JSON von Hand bearbeiten, bekommen laute Diffs.

Wenn ein Payload als eine komprimierte Zeile ankommt, oeffnen Sie den JSON Minifier & Formatter, um ihn zu beautifizieren, Klammern zu validieren und vor dem Versand wieder zu minifizieren.

YAML: Config, die Menschen wirklich bearbeiten

YAML (YAML Ain't Markup Language) ist fuer Menschen zuerst gedacht. Einrueckung ersetzt die meisten Klammern. Kommentare mit #, mehrzeilige Bloecke mit | oder >, und Wiederverwendung mit Ankern (&name) und Aliases (*name). Diese Kombination machte YAML zum Default fuer Kubernetes-Manifeste, Docker Compose, GitHub Actions und viele App-Config-Dateien.

Kommentare und Anker

Kommentare sind das Feature, das JSON fehlt. Eine Zeile mit # dokumentiert, warum ein Timeout 30 Sekunden ist, ohne Laufzeitdaten zu aendern. Anker gehen weiter: definieren Sie einen gemeinsamen logging-Block einmal mit &logging, ziehen Sie ihn in mehrere Services mit *logging, optional Keys mit <<: ueberlagern. Vorsichtig genutzt sparen Anker Duplikate. Unvorsichtig machen sie Dateien schwer lesbar und ueberraschend beim Mergen in Git.

• Am besten fuer: Deployment- und CI-Config, Feature-Flags, die Menschen bearbeiten, kleine Dokumente, bei denen Lesbarkeit wichtiger ist als Wire-Groesse.
• Staerken: Kommentare, Anker/Aliases, mehrzeilige Strings, weniger Interpunktions-Laerm.
• Grenzen: Einrueckungsfehler, implizite Typ-Ueberraschungen und groessere Angriffsflaeche, wenn Sie untrusted YAML mit unsicheren Loadern parsen.

CSV: flache Tabellen fuer Tabellenkalkulationen

CSV (Comma-Separated Values) ist ein Raster: Spalten und Zeilen. Tabellenkalkulationen, BI-Tools und Datenpipelines verstehen es. Es gibt kein verschachteltes Objekt, keinen Array-Typ und meist keinen Boolean-Typ - alles ist Text, bis Ihr Importer castet. Das passt, wenn Ihre Daten schon eine Tabelle von Nutzern oder Bestellungen ist. Es bricht zusammen, wenn die Quelle ein Baum ist.

Warum CSV Typen und Verschachtelung verliert

• Typen: "42", 42 und true kommen alle als Strings an, wenn Sie kein Schema definieren. Fuehrende Nullen in ids und Telefonnummern streicht Excel weg.
• Verschachtelung: eine Adresse mit street und city wird zu address.street-Spalten, einem JSON-Blob in einer Zelle oder duplizierten Elternzeilen.
• Arrays: tags werden oft eine Zelle mit Trennzeichen (admin;beta), die Sie spaeter splitten muessen.
• Null vs leer: eine leere Zelle kann null, leeren String oder fehlende Spalte bedeuten - Konventionen unterscheiden sich.

Ist Ihre Quelle verschachteltes JSON, konvertieren Sie bewusst mit dem JSON to CSV Converter und entscheiden Sie, wie Arrays und verschachtelte Keys geflacht werden, bevor Sie die Datei an eine Tabellenkalkulation geben.

Wann welches Format die richtige Wahl ist

APIs und Maschine-zu-Maschine

Bevorzugen Sie JSON. Clients erwarten application/json, Tooling ist ueberall, und das Typsystem reicht fuer die meisten Vertraege. YAML als HTTP-Body ist selten und meist ein Fehler. CSV als API-Antwort ergibt nur Sinn fuer Bulk-Export-Endpunkte, die Excel oder Data Warehouses speisen.

Config-Dateien

Bevorzugen Sie YAML (oder ein typisiertes Format wie TOML), wenn Menschen die Datei bearbeiten und Kommentare brauchen. Bevorzugen Sie JSON, wenn die Config generiert wird, von einem Schema validiert wird oder meist von Tools bearbeitet wird. Halten Sie YAML-Dokumente klein und reviewt - tiefe Anker und Custom Tags altern schlecht.

Tabellenkalkulationen und Analytics

Bevorzugen Sie CSV (oder ein echtes Tabellenformat), wenn der Consumer Excel, Google Sheets oder SQL COPY ist. Flachen Sie Ihr Modell zuerst. Behalten Sie JSON als System of Record und exportieren Sie CSV als View.

Klassische Fallen

YAMLs Norway-Problem

In YAML 1.1 werden mehrere unquoted Strings als Booleans geparst: yes, no, on, off, true, false (und einige Locale-Varianten). Der Laendercode NO fuer Norwegen wird boolean false. Versionsstrings wie 1.10 werden zu Floats. Quoten Sie Werte, die wie Booleans, Zahlen oder Datums aussehen, wenn sie wirklich Strings sind: country: "NO". Bevorzugen Sie YAML-1.2-Parser wenn moeglich, und quoten Sie trotzdem verdaechtige Scalars.

CSV-Kommas in quoted fields

Felder mit Kommas, Anfuehrungszeichen oder Zeilenumbruechen muessen in doppelte Anfuehrungszeichen. Ein Anfuehrungszeichen im Feld wird durch Verdoppeln escaped: "Ada ""Lovelace""". Ein naiver Split an Kommas zerstoert solche Zeilen. Nutzen Sie immer einen echten CSV-Parser oder -Exporter - auch beim Round-Trip ueber den JSON to CSV Converter. Locale-Einstellungen zaehlen: manche Regionen nutzen Semikolon als Trennzeichen, Excel erwartet trotzdem Kommas oder umgekehrt.

Weitere Stolpersteine

• JSON: trailing commas und Kommentare aus JavaScript-Objektliteralen scheitern an strikten Parsern.
• YAML: Tabs vs Spaces, unsichere Loader die Tags ausfuehren, und riesige Dokumente, die Merge-Fehler verstecken.
• CSV: kein einheitlicher Standard fuer Encoding, Trennzeichen oder Zeilenenden; dokumentieren Sie immer UTF-8 und Ihr Separator-Zeichen.

Vergleich nebeneinander

• Verschachtelung - JSON und YAML: natuerliche Baeume. CSV: flachen oder Struktur verlieren.
• Typen - JSON: string, number, bool, null, array, object. YAML: reichere Scalars (plus Ueberraschungen). CSV: Text bis zum Cast.
• Kommentare - JSON: keine. YAML: # comments. CSV: keine Standard-Kommentare.
• Bearbeitung durch Menschen - YAML gewinnt meist; JSON okay fuer kleine Dateien; CSV gewinnt in Tabellenkalkulationen.
• Wire / API - JSON ist der Default. YAML und CSV sind Randfaelle.
• Tooling - konvertieren mit JSON to CSV und YAML to JSON; JSON formatieren mit dem JSON Minifier & Formatter.

Haeufige Fragen

Ist YAML besser als JSON?

Fuer von Menschen bearbeitete Config mit Kommentaren oft ja. Fuer APIs und Austausch ist JSON besser: strikter, vorhersagbarer und universell unterstuetzt. Viele Teams schreiben YAML und kompilieren oder konvertieren zu JSON fuer die Laufzeit.

Kann CSV verschachteltes JSON darstellen?

Nur durch Flatten. Verschachtelte Objekte werden zu dotted columns oder JSON-in-a-cell-Strings; Arrays werden zu delimited lists oder wiederholten Zeilen. Nutzen Sie CSV, wenn der Consumer eine Tabelle braucht, nicht wenn Sie den ganzen Baum erhalten muessen.

Soll ich Config in JSON oder YAML speichern?

Wenn Menschen sie woechentlich bearbeiten und Kommentare hinterlassen, YAML (oder TOML). Wenn ein Schema-Validator oder Codegen die Datei besitzt, JSON. Vermischen Sie nicht beides als dieselbe Source of Truth.

Was ist das Norway-Problem in YAML?

Unquoted NO (und aehnliche Tokens) kann in YAML 1.1 als boolean false geparst werden. Quoten Sie Laendercodes und andere stringartige Scalars, oder nutzen Sie einen YAML-1.2-Parser, der sie als Strings behandelt.

Wie konvertiere ich zwischen diesen Formaten?

Nutzen Sie den YAML to JSON Converter fuer Config in API-Form, und den JSON to CSV Converter fuer tabellarischen Export. Beautifizieren oder minifizieren Sie JSON mit dem JSON Minifier & Formatter. Alle drei laufen in Ihrem Browser.

JSON, YAML und CSV auf ToolsMinify konvertieren

Jedes Tool unten laeuft vollstaendig in Ihrem Browser - kostenlos, ohne Anmeldung, nichts wird hochgeladen:

• JSON-zu-CSV-Konverter - JSON-Array von Objekten in eine herunterladbare CSV-Tabelle verwandeln.
• YAML-zu-JSON-Konverter - YAML-Config in JSON fuer APIs und Validatoren parsen.
• JSON Minifier & Formatter - JSON pretty-printen oder minifizieren und Syntaxfehler frueh finden.
• Alle Konverter-Tools - der volle Kategorie-Index.