CSV vs JSON vs XML: Which Data Format Should You Use?

What is CSV?

CSV stands for comma-separated values. It stores a table as plain text: each record sits on its own line and fields are separated by commas. RFC 4180 describes the common format and registers the text/csv media type, although it is an informational document rather than a strict standard, which is one reason real-world CSV files vary.

The rules are simple. A header line is optional, each line should contain the same number of fields, and fields that contain commas, double quotes, or line breaks must be wrapped in double quotes, with any quote inside a field written twice. Spaces count as part of a field.

• Best for: flat, row-and-column data such as exports, contact lists, transactions, and anything destined for a spreadsheet.
• Strengths: very compact, readable in any text editor, and supported by spreadsheets and databases everywhere.
• Weaknesses: no data types, no nesting, no standard way to describe columns beyond a header, and inconsistent handling of delimiters and encodings between programs.

What is JSON?

JSON, or JavaScript Object Notation, is a text format for structured data defined in RFC 8259. It represents objects (named values), arrays (ordered lists), strings, numbers, booleans, and null, and objects and arrays can be nested inside one another. Mozilla describes it as a text-based data format following JavaScript object syntax that many programming environments can read and write independently of JavaScript. JSON files use the .json extension and the application/json media type.

• Best for: web APIs, application configuration, and any data with a nested or irregular structure.
• Strengths: it maps directly onto the objects and lists in most programming languages, carries basic types (text, numbers, true and false, null), and stays readable.
• Weaknesses: it repeats field names in every record, so it is bulkier than CSV for plain tables; it has no comments and no native date type; and very large numbers can lose precision in some parsers.

What is XML?

XML, the Extensible Markup Language, describes data with nested, named tags and attributes. The W3C recommendation (the fifth edition of XML 1.0, dated 26 November 2008) lists design goals that include usability over the Internet, support for a wide variety of applications, and human readability. Every well-formed XML document has exactly one root element, and its elements must nest properly inside each other.

XML grew into a family of related standards for schemas, namespaces, transformations, and queries, and it still underpins many document formats, feeds, and enterprise systems. RSS feeds and XML sitemaps, for example, are both XML.

• Best for: documents with mixed content, formats defined by an industry standard, and systems that require formal schema validation.
• Strengths: mature validation and namespace support, attributes alongside elements, and a long track record in enterprise and publishing workflows.
• Weaknesses: it is verbose because every element has opening and closing tags, harder to read at a glance, and more work to parse and generate than JSON for simple data.

CSV vs JSON vs XML: the differences that matter

Rather than a long table, here are the differences that decide the choice in practice.

• Structure: CSV is flat rows and columns, JSON is nested objects and arrays, and XML is a tree of elements and attributes.
• Data types: CSV has none, so everything is text until a program interprets it. JSON has text, numbers, booleans, and null. XML treats content as text unless a schema defines types.
• Readability: CSV reads like a table, JSON reads like code, and XML reads like markup. For small, simple data, CSV and JSON are the easiest to scan.
• Size: CSV states column names once, while JSON and XML repeat names for every record and XML also repeats closing tags. For plain tables, CSV is typically the most compact and XML the largest.
• Validation: CSV has no built-in validation, JSON can use a separate schema language, and XML has long-established schema support.
• Comments: CSV and JSON have none, while XML supports them.

Which data format should you use?

Start with one question: who or what will read this file next? The answer usually decides the format.

If you are unsure, JSON is a sensible default for data that software will process, and CSV is a sensible default for data that people will open in a spreadsheet.

• Opening in Excel, Google Sheets, or a database import: choose CSV.
• Sending data to or from a web or mobile app, or saving settings: choose JSON.
• Meeting an industry standard, a partner's requirement, or a schema that must be enforced: choose XML.
• Records with variable fields or nested lists, such as an order with many line items: choose JSON or XML, not CSV.
• Very large, simple tables where file size matters: choose CSV.

Real-world examples: which format fits which job?

Abstract comparisons only go so far, so here is how the choice plays out in everyday situations. In each case the format follows the reader: the data is the same, and what changes is who needs to open it and what they can do with it.

• Exporting customers from a store or CRM: CSV. Non-technical colleagues can open it in a spreadsheet, filter it, and import it again.
• Sending an order to a payment or shipping API: JSON. An order has a customer, an address, and a list of line items, which is exactly the nested shape JSON handles well.
• Publishing a news feed or telling search engines about your pages: XML. RSS feeds and XML sitemaps are defined XML formats, so the choice is made for you.
• Storing app settings: JSON. It is readable, easy to edit, and every language can parse it, although you cannot add comments.
• Sharing a large dataset with an analyst: CSV, plus a short note describing the columns, units, and encoding, because the format itself cannot carry that information.
• Exchanging data with an older enterprise system: ask for its specification first. Many such systems expect XML that follows a particular schema.

How to tell what format a file really is

Because all three formats are plain text, you can open any of them in a basic text editor to see what you are dealing with. A CSV starts with a header line of column names separated by commas, or sometimes semicolons or tabs. A JSON file starts with { or [. An XML file usually starts with an optional declaration such as <?xml version="1.0"?> followed by a single root element.

Doing this on your own computer is safe for sensitive files, because opening a file in a text editor never sends it anywhere.

• If the first line looks like names separated by commas, semicolons, or tabs, it is delimited text. Check which separator it uses before importing.
• If it begins with { or [, it is probably JSON, and a validator will confirm it.
• If it begins with an angle bracket, it is XML or HTML. Look for a single root element.
• If accented characters look garbled, the encoding is probably not UTF-8. Re-save the file as UTF-8.

Common problems when working with CSV

CSV looks too simple to fail, which is why it fails so often. Microsoft's documentation notes that when Excel opens a .csv file it uses its current default data format settings to interpret each column. That is how long numbers get reformatted, dates change, and leading zeros vanish from codes such as ZIP codes and phone numbers. Excel's import wizard lets you set a column's format to text to preserve them.

The separator can also change. Microsoft explains that the default list separator when saving a .csv file is a comma but can be changed in Windows Region settings, so a file can use a different separator on another computer. A file that opens correctly on one machine may collapse into a single column on another. Finally, fields that contain commas or line breaks must be quoted as RFC 4180 describes, and hand-built CSV that skips this breaks the first time someone types an address.

The reliable habits are the same everywhere: use UTF-8 encoding, include a header row, quote fields consistently, and keep one record per line.

Common problems when converting between formats

Converting between these formats is where most data quality problems appear, because each format can express things the others cannot.

Because these files often contain customer lists, financial exports, or internal records, convert them with a tool that runs in your browser or on your own computer rather than uploading them to an unknown server.

• CSV to JSON: everything arrives as text, so numbers, dates, and true or false values need explicit conversion. Decide how to treat empty cells: an empty string, null, or omitted.
• JSON to CSV: nested objects and arrays do not fit in columns. Flatten them (for example, address.city becomes its own column) or split them into separate tables. Arrays of different lengths force awkward choices.
• XML to JSON: attributes, mixed text, repeated elements, and element order have no single standard mapping, so different converters produce different JSON. Agree on a mapping before relying on one.
• Large numbers: RFC 8259 notes that integers beyond 2^53 are not guaranteed to be interoperable, so store large identifiers as strings.
• Encoding: save and read all three formats as UTF-8 to avoid garbled accents and symbols.