CSV vs JSON vs Parquet: which file format should you use?

A data engineer's day includes a lot of opening files. One partner sends orders as a CSV. A website's API returns JSON. The data lake holds Parquet files. They all contain the same kind of information, tables of facts, but they store it very differently, and the differences decide what is fast, what is safe and what is painful.

CSV: the simplest format

CSV stands for comma-separated values. It is plain text where every line is a row and commas separate the values. The first line usually holds the column names.

You can open it in any text editor or in Excel, and almost every tool can read and write it. That is its strength: it works everywhere.

Its weaknesses are the ones that bite beginners:

• No data types. Everything is text. Is 007 a number or an ID? Is 03/04/2026 the 3rd of April or the 4th of March? The file does not say, so tools guess, and sometimes guess wrong. A leading zero can vanish.
• Commas inside values. The name Sharma, Asha has a comma in it, so it needs quotes, and quotes inside values need escaping. Badly written CSVs break at exactly these points.
• No nesting. One flat table only.
• Large and slow. Numbers are stored as characters, nothing is compressed, and a tool must read the whole file even if you want 1 column.

JSON: values with names, and nesting

JSON stores data as names and values, and it can nest them. One order can contain a list of items inside it. It is the usual language of web APIs and application logs.

Its strength is that it can represent messy, nested real-world data, such as an order with several items, in 1 record, and it carries the column names with every record, so a reader can see what each value means.

Its weaknesses are size and speed for tables. Every record repeats the names of all its fields, which wastes space, and a tool must read and parse the text of everything. It is also awkward to load into a flat table, because nested parts must first be flattened. A common variant is JSON Lines, one JSON record per line, which suits large files because it can be read line by line.

Parquet: built for analytics

Parquet is a binary format, which means you cannot read it in a text editor, but tools read it very fast. It has three big ideas.

• It stores data by column. All the amount values sit together, all the city values together. A report that needs only 2 columns reads only those two and skips the rest. This is the column-by-column storage described in OLTP vs OLAP.
• It is compressed. Values in 1 column are similar to each other, so they compress very well, and Parquet files are usually much smaller than the same data in CSV or JSON.
• It stores the types and column names inside the file. An integer is an integer and a date is a date. Nothing is guessed.

The costs are that humans cannot open it casually, and that it is designed for writing in big chunks, not for editing single records. That is fine for analytics, where data is added in batches and read many times.

The three side by side

There are other formats too, such as Avro, which stores data row by row with its schema and is common with Kafka, and ORC, a column format similar to Parquet. If you know these three, you can learn the rest quickly.

Which one should I use?

• Receiving data from a person or a partner: CSV, because it is what they can produce. Check the types and encoding when you read it.
• Receiving data from an API or an app: JSON.
• Storing data for analysis in a lake or warehouse: Parquet.

The usual professional pattern joins them: accept CSV and JSON because that is what the sources send, then convert to Parquet once, clean, and query the Parquet from then on. That conversion is one of the first things a data pipeline does. You will meet Parquet again when you read about the lake and lakehouse, where almost everything is stored in it, and in the PySpark track, where you read and write these formats yourself.