18Docs

CSV vs JSON vs YAML vs XML

CSV, JSON, YAML and XML all store structured data, but they were built for different jobs. Picking the right one — and knowing how they convert — saves a lot of friction when moving data between spreadsheets, code, configs and APIs.

What each format is good at

CSV is a flat table: rows and columns, nothing more. It is perfect for spreadsheets and tabular exports, and almost every tool reads it — but it cannot express nesting or hierarchy. JSON is the language of APIs and modern apps: compact, supports nested objects and arrays, and is easy for code to parse. YAML is JSON's more human-friendly cousin, using indentation instead of brackets, which is why it dominates configuration files. XML is the verbose, highly structured elder, still common in enterprise systems, document formats and older APIs.

Converting between them cleanly

Converting flat data is straightforward: a CSV table maps neatly to a JSON array of objects, YAML, or XML records. The friction appears with nesting — CSV cannot represent the nested structure that JSON, YAML and XML can, so converting a deeply nested JSON to CSV means flattening it, which can lose hierarchy. Going the other way, from CSV up to JSON, is usually clean.

When you convert, watch types and encoding: numbers, booleans and dates should survive as the right type, and text with commas or special characters needs proper quoting. A good converter handles that for you, and running it in your browser keeps the data — which may be sensitive — off any server.

Tools for this

Frequently asked questions

Why can't my nested JSON convert to CSV cleanly?
CSV is a flat table and cannot represent nesting. Nested JSON has to be flattened to fit columns, which can lose some of the hierarchy.
Which format is best for configuration files?
YAML is popular for configs because its indentation-based style is easy for people to read and edit; JSON is also common where tooling prefers it.