CSV vs JSON vs XML vs YAML vs TOML: Which Data Format, and How to Convert
Most data you handle day to day is in one of five text formats — CSV, JSON, XML, YAML or TOML — plus Excel workbooks, which are XML in a ZIP file. They overlap a lot, which is why converting between them is so common, but each one has things the others can't say. Knowing those gaps is what stops a conversion from quietly changing your data.
The formats side by side
| Format | Specification | Shape | Types | Comments | Typical use |
|---|---|---|---|---|---|
| CSV | RFC 4180 (2005) | Flat rows | None — all text | No | Spreadsheet exports, bulk imports |
| JSON | RFC 8259 (2017) | Tree | string, number, boolean, null | No | APIs, web apps, NoSQL |
| JSON Lines | jsonlines.org | One JSON value per line | As JSON | No | Logs, data pipelines, ML datasets |
| XML | XML 1.0 Fifth Edition (2008) | Tree with attributes | None without a schema | Yes | Feeds, documents, enterprise and SOAP systems |
| YAML | YAML 1.2.2 (2021) | Tree (indentation) | string, int, float, bool, null | Yes | Kubernetes, CI pipelines, Ansible |
| TOML | TOML 1.0.0 (2021) | Tree of tables | string, integer, float, bool, date-time | Yes | Cargo, pyproject.toml, Hugo |
| Excel .xlsx | ECMA-376 / ISO/IEC 29500 | Grids (sheets) | number, text, boolean, date serials | Cell notes | Business data, reports |
Which one to pick
Tables of records that people will open in a spreadsheet: CSV, or a real .xlsx file when the data has leading zeros, long numbers or non-English text. CSV is the lowest common denominator — every database and spreadsheet reads it — but it carries no types, so the reader has to guess.
Data exchanged between programs: JSON. It has real types and nesting, every language parses it, and it's strict enough that two parsers almost always agree. Use JSON Lines when records are streamed or appended, because each line can be processed alone.
Configuration humans edit: YAML or TOML. TOML is the safer choice for flat-to-medium configs: it's explicit, has native dates and no indentation rules. YAML wins for deeply nested structures and is the standard for Kubernetes and most CI systems, but its implicit typing has famous traps (below).
Documents and systems that already speak it: XML. Its attributes, namespaces and mixed text make it the right fit for documents, RSS and Atom feeds, sitemaps and many enterprise integrations — and the wrong fit for simple records, where it is mostly overhead.
Conversion traps
Leading zeros and long numbers
A ZIP code 02139, an employee code 00742 or a 16-digit account number looks numeric, but it isn't a number. Converters that type values blindly turn them into 2139, 742 or 4111111111111110. ToolFeather's converters keep any value with a leading zero, a plus sign or more than 15 digits as text, because JavaScript numbers (and Excel cells) hold only about 15–17 significant digits — integers above 9,007,199,254,740,991 can't be stored exactly in JSON as parsed by browsers.
The Norway problem
YAML 1.1, still used by PyYAML and many tools, reads unquoted yes, no, on and off as booleans — so the country code NO becomes false. YAML 1.2 fixed this, but you can't control which parser reads your file. When converting CSV to YAML or JSON to YAML, such values must be quoted; dates like 2026-10-21 too, since many parsers turn them into date objects.
TOML has no null
JSON and YAML have null; TOML doesn't. A converter has to drop those keys or invent a value. JSON to TOML leaves them out and lists each one, so you can decide. TOML also requires the root to be a table, so a top-level array has to be wrapped.
XML attributes and single-item lists
JSON has no attributes, so XML to JSON needs a convention: here, attributes become keys prefixed with @ and text beside them goes into #text. The bigger trap is repetition: two <item> elements become an array, one becomes an object — and code that loops over it breaks. Force arrays when the JSON feeds code.
Flattening trees into tables
Going from JSON, XML or YAML to CSV or Excel means flattening. Nested objects become dotted columns like address.city; lists of values can be joined into one cell; lists of objects can't fit a single row and are kept as JSON text. If your data has several lists, convert each to its own sheet — JSON to Excel does that automatically.
Spreadsheets and Excel
Double-clicking a CSV in Excel is where most data damage happens: Excel may guess a legacy encoding (so é becomes é), strip leading zeros, show long numbers as 1.23E+15, and turn values like 1-2 into dates. Three habits avoid it: add a UTF-8 byte-order mark when you save CSV for Excel, import with Data → From Text/CSV and set sensitive columns to Text — or skip CSV and hand people an .xlsx in which every cell already has the right type. In the other direction, Excel to CSV gives you stored values, not formatting: a cell showing 15% is 0.15, and date cells (stored as serial numbers counted from 1899-12-30) come out as ISO dates.
Converting safely
- Look before you convert. Open a CSV in the CSV viewer to check delimiters, empty columns and "mostly numeric" columns that hide stray text.
- Prefer converters that report. A good converter tells you which values it couldn't represent (nulls in TOML, inf in JSON) instead of silently changing them.
- Keep identifiers as strings at the source — in JSON, write
"id": "9007199254740993", not a bare number. - Round-trip once. Convert A → B → A and diff the result; anything that changes is something B can't hold.
- Keep private data private. Exports often contain customer details or secrets. Every converter on ToolFeather runs in your browser — nothing is uploaded.