Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is CSV considered a good option against XML and JSON for programming languages?

I generally use XML and JSON (or sometimes a plain text file) as flat file storage. However, recently I came across an CSV implementation in PHP. I generally have seen CSV used for inputs in Excel files though, but I have never used it with programming. Would it be better than XML or JSON in any way?

share|improve this question

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, GlenH7, psr, MichaelT Jan 22 at 22:09

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This quetion is vague. Are you asking if CSV makes a better format as a storage system, or are you asking if there are any reasons to use CSV over XML/JSON? –  GrandmasterB Jan 21 at 18:26
Any CSV message structure can be mapped to an XML or JSON message format. Not all XML/JSON message format can be mapped to CSV. So, CSV only covers a specific data use case, tabular format, where as JSON and XML can cover more complex message structures. –  Jon Raynor Jan 21 at 21:39
@JonRaynor: I think any XML or JSON format can be mapped to CSV -- but not cleanly. You'd have to invent some way of representing the tree structure. The result would be ugly and almost certainly not worth implementing. For almost all practical purposes, you're right. –  Keith Thompson Jan 22 at 20:00

6 Answers 6

up vote 24 down vote accepted

The answer is, it depends.

CSV is great for certain use cases. For example as a "streaming" format for large datasets it's easier to stream than XML/JSON and take much less storage space. I use it to stream datasets in the gigabyte range where other formats are impractical.

It's also a /really/ common in certain industries when dealing with legacy systems and workflows. Try importing JSON into MS Excel.

The ODI recently commented about CSV. Calling 2014 "The year of CSV" http://theodi.org/blog/2014-the-year-of-csv

For "proper" CSV look at the CSV mime type RFC 4180.

share|improve this answer
+1 for legacy systems; while the legacy system may not be using the CSV in an intended manner (I've recently had to deal with importing a CSV that was, honestly, a report, not a table), we do have to deal with legacy information throughout the world. –  Brian S Jan 21 at 19:42
+1 for streaming –  Adrian Schneider Jan 22 at 19:43
CSV has the streaming advantage which is a big deal: the CSV parser has much less state to deal with than the JSON or XML parsers. –  Matt Jan 22 at 20:33

Most certainly not.

CSV is a table format that maps very well to data sets or other tabular data. But not all data is tabular! Most generally, we want to serialize object graphs. This can be difficult in the following cases:

  • circular references
  • shared subgraphs (e.g. two objects that both contain the same object as a member)
  • objects of different types to be serialized to the same document

We further want to be able to reliably de-serialize the objects from our storage format.


Is primarily an extensible markup language. It can be shoe-horned to store general data structures as well. Language support for IDs means that complex graphs can be created, although it's best used for trees. A document can be tested for correctness against a specification. There are various problems with this format that can make it impractical, such as the extreme verbosity.


Is primarily a way to store simple object trees. There is no support for general graphs. JSON has no concept of type beyond primitives string, integer, float, boolean, null and the collection types array and object.


Most easily understood as an extension of JSON. Has a notion of aliases that allow object graphs of arbitrary complexity to be created. Has a concept of metadata like tags that can be used for proper typing.


Has nothing, except a single table. If we want to store object graphs, we would have to use a schema like



There are many dialects of CSV that disagree on delimiters, line terminators, quoting, escape characters, and many other issues that make it unsuitable for general (binary) data. All of this makes it rather difficult to process CSV data.

So basically, easy things are difficult or impossible with CSV when using it as a general serialization format.

This criticism does not apply when using it to store truly tabular data like time sheets or a series of measurements. Here, CSV (often in the variant of tab separated values) is usually more compact and easier to use than the other data formats.

share|improve this answer
I think this is a fair argument. They're different, so use them for different things, use each where it's best. –  Ben Jan 21 at 19:32
Without the first line this would be a good answer. CSV is a good alternative to XML for tabular information (a distributable SQLite file is probably better than both). But as you explain for tabular data is it the superior file choice. –  Lego Stormtroopr Jan 21 at 23:48


CSV is not really a single format. There is a wide variety of styles for escaping, separators, and other formatting issues that many CSV files in the wild have.

If you are going to be using this as a flat file storage, using JSON will serve you much better. JSON maps to and from objects with much less hassle than you will have kludging CSV to do so.

share|improve this answer

I'd also have to say that it depends on what you are trying to achieve. For many problems it doesn't matter much what you choose if the problem is small enough and your choice fits well with the existing system.

Taking a legacy system and trying to shoehorn in a new format can sometimes be a problem as you've introduced more complexity and have a new input system to debug. I've seen this a lot when new people prefer something different than what exists, or when a new format appears and they want to experiment with it. This may or may not be a good idea, it depends on circumstances.

Years ago I worked on a research graph database system that depended on CSV files of various formats. The CSV file importer would build graphs for us and it had many years of work done to debug and optimize the code. It was both fast and flexible and we'd happily use it to bootstrap large research projects. When XML appeared on the scene we added an XML importer but it was not necessarily an improvement in terms of speed or expressing complexity, and certainly XML was not any better at expressing graph structures than CSV. JSON is a lot nicer (and terser) than XML but is similar in many respects so I'd expect a similar result when creating an new importer on that system.

At one point in time we had a customer bring in a massive amount of data in (as we called it) "cobol" format, files with lines of variable length containing markers that indicated how to interpret the bytes that followed on that line. It came from a time when storage was expensive so compactness was a requirement. We imported that data by converting it into CSV format on the fly and feeding it into the CSV importer. That was easy to do and minimized the amount of debugging and maintenance, which are good things. If we had to import that kind of data all of the time we might have built it into the system directly to get performance and efficiency gains.

So, it depends on what you're doing and on what the underlying system does. In my example the CSV importer was solidly engineered and dependable. I'd hesitate to tell you that one format was better or worse without understanding what is going on in the other layers I am building. I love JSON and prefer it, but I know that given certain complex data structures and large enough data sets, CSV files can be made to work very well, too.

share|improve this answer

I would strongly advise against it. I might be OK to output CSV at some point (if the user requests it). But it is a bad fit for storage / import purposes. This is mostly due to the fact that "CSV" is very ill-defined. Does the "C" indicate "comma" or "character" separated? How do you treating text strings which are containing escape characters like "? Every damned CSV implementation treats escape characters etc. differently, which leads to files which can be ex- but not imported etc.

Excel is a good demonstration: In the english version it uses "," as separator. In Germany, it uses ";". So a german version chokes on english CSV files, and vice versa ...

It's main strength is human readability, which should not be discounted. But I would not rely on it as a storage format, it is too brittle for that purpose. If you have to export files for humans, you might use CSV but even then I would try to use a library which writes to xlsx files (they are freely available).

share|improve this answer
It's "comma", see RFC 4180. Just because Microsoft broke something in Germany doesn't mean a standardised format is useless... –  Ben Jan 21 at 19:31
No, it is not "Comma" - it can also mean "character separated" and the problem is not confined to germany. Yes, the RFC specifices otherwise, but a file named "csv" can contain a crapload of different seperators, escape styles etc. When you try to import such a file your program will import...something, but not what you want. –  Christian Sauer Jan 22 at 7:28

In General NO. Why? JSON and XML are there basically to get rid of the dreaded CSV. They're the structured approaches of what has been done unstructured with CSV for a long time. Yes, there are some use-cases where CSV is still prefered but in general in 9 out of 10 cases you're better off not using CSV.

share|improve this answer
Unless of course the data you're transferring is "flat". You then save a huge amount by not transferring useless XML tags etc. –  Ben Jan 21 at 19:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.