JSON vs CSV vs YAML vs XML: when to use each, and what breaks when you convert

The same record in four formats

The easiest way to see the differences is to write one record four ways. The data: a customer called Asha Rao, with a zip code that starts with zero, an active flag, and two tags.

Notice that only JSON, YAML and XML can express the list of tags natively. CSV flattens everything to a grid of text cells, and that is both its strength and its limit.

• JSON: {"name": "Asha Rao", "zip": "02134", "active": true, "tags": ["new", "vip"]}
• CSV: a header line name,zip,active,tags followed by the row Asha Rao,02134,true,"new;vip". Tags had to be squeezed into one cell using a made-up separator.
• YAML: name: Asha Rao, then zip: "02134", then active: true, then tags as a list with the items new and vip on separate lines, using indentation to show structure.
• XML: a customer element with child elements name, zip, active and a tags element containing two tag elements.

When each format is the right choice

A rule of thumb: if a program talks to a program, use JSON. If a person in a spreadsheet has to open it, use CSV. If a person edits it by hand and needs comments, use YAML. If an industry standard or older system requires it, or the data is really a document with markup, use XML.

Pick the format by who or what reads it, not by habit.

Pitfall 1: nested data does not fit in a table

CSV is a grid; JSON is a tree. Converting a tree to a grid needs decisions. An order with three line items could become three rows that repeat the order number, one row with the items joined into a single cell, or columns like item1, item2, item3. Each choice loses something or breaks round-tripping. The JSON to CSV tool on this site flattens nested objects into columns using dotted names such as address.city, which works for objects with a fixed shape but not well for arrays of different lengths. Review the output before using it, and keep the original JSON.

Going from CSV to JSON is easier, but each row becomes a flat object. If you need nesting, you must rebuild it from column names.

Pitfall 2: types disappear

JSON knows that 42 is a number and "42" is a string. CSV knows neither; everything is text, and the program or spreadsheet that reads it guesses. A column of 1.5 and 2 may be read as numbers; a column containing true may become a boolean in one tool and text in another. Dates are worse, because JSON has no date type either and CSV has no format rules: 03/04/2026 means different days in different countries. YAML has a different trap, called implicit typing. Depending on the parser, a bare value like no, on or 1e3 may become a boolean or number, and a version such as 1.10 may be read as the number 1.1. Quote values whose type matters.

Pitfall 3: leading zeros and long numbers

Zip codes, phone numbers, account numbers and product codes that begin with zero are identifiers, not numbers. In the record above the zip is 02134. Open a CSV in a spreadsheet and it may display 2134, because the spreadsheet decides the column is numeric and discards the zero. Saved again, the damage is permanent. Long numbers suffer too: a 16-digit card number or an ID may be shown in scientific notation, and digits beyond about 15 significant ones can be rounded, because spreadsheets store numbers as double-precision floating point. In JSON, the same applies to JavaScript parsers: integers larger than 9,007,199,254,740,991 lose precision. The safe approach is to store identifiers as strings, set the column to text on import, and quote them.

Pitfall 4: encoding, BOMs, delimiters and quotes

CSV files have no declared encoding. UTF-8 is the common choice for exchange, but some spreadsheet programs assume a legacy encoding unless the file starts with a byte order mark (BOM), three bytes at the start of the file. With the BOM, accented letters and non-Latin scripts display correctly in such programs; without it, you may see garbage like "é" for "é". The opposite problem occurs in programs that do not expect a BOM: the first header becomes an invisible character plus the name, so a lookup for "name" fails. If a column mysteriously cannot be found, a BOM is a suspect.

Delimiters are another trap. Many European locales use a semicolon as the list separator because the comma is the decimal mark, so a "CSV" from one machine may not parse on another. The CSV Delimiter Converter on this site changes between comma, semicolon, tab and pipe. Quoting also matters: a field containing a comma, a quote or a line break must be wrapped in double quotes, and an inner quote doubled. Hand-built CSV that skips this breaks on a name like O'Neil, "Jr." or an address with a line break.

JSON and XML are stricter. JSON requires double quotes and forbids trailing commas, comments and single-quoted strings. XML requires escaping of the characters &, < and >, and a single root element.

Treat identifiers as text, save as UTF-8, and check the delimiter before importing a CSV.

Converting safely: a checklist

This site includes JSON to CSV, CSV to JSON, JSON to YAML, YAML to JSON, JSON to XML and XML to JSON converters, all running in the browser so private data is not uploaded. They are good for configuration, test data and small datasets. For very large files, or data with complex rules, a script or database import is a better fit.

1. Keep the original file. Conversions are not always reversible.
2. Decide how you will represent lists and nesting, and write it down.
3. Convert a small sample first, and look at the first and last rows, any row with a comma, a quote or an empty value, and a row with a leading zero.
4. Compare record counts before and after. Use the JSON Diff tool to compare two JSON files.
5. Validate the result: the JSON Formatter reports syntax errors, and the XML Formatter does the same for XML.
6. Check that identifiers are still text and dates are in a format the next system expects.

Frequently asked questions

Try these tools