Why should I use a human readable file format?

Question

Why should I use a human readable file format in preference to a binary one? Is there ever a situation when this isn't the case?

EDIT: I did have this as an explanation when initially posting the question, but it's not so relevant now:

When answering this question I wanted to refer the asker to a standard SO answer on why using a human readable file format is a good idea. Then I searched for one and couldn't find one. So here's the question

Answer 1

A major reason is that if someone needs to read the data say, 30 years from now, human readable format can be figured out. Binary is much more difficult.

If your have large data sets that are binary by nature (e.g. images), they obviously can't be stored in any other than binary form. But even then, the metadata could (and should!) be human-readable.

Answer 2

• Open format -- no binary bit juggling
• Readability :)
• Interchange across platforms
• Debugging aid
• Easily parsed (and easily converted to any format)

One important point: you write a parser once, but read the output many times. That kind of tilts the balance in favor of HRF.

Answer 3

They open the possibility to be created/edited with tools other than the original ones. New and better tools can be developed by others, integration into third party applications becomes possible. Think about binary iCal files, for example - would the format have been a success?

Apart from that: Human readable files improve the ability to debug or, for the savvy user, at least find the reason an error.

Answer 4

Why should I use a human readable file format in preference to a binary one?

Depends on the content and context, i.e. where is the data coming from and going. If the data is typically directly written by a human, storing it in an format that can be manipulated through a text editor is a good idea. For example, program source code will normally be stored as human readable with good reason. However, if we are archiving it, or sharing it using a version control system, our storage strategy will change.

Answer 5

When reading Fielding's dissertation about REST, I really liked the concept of "Architectural Properties"; one that sticked was "Visibility". That's what we're talking about here: being able to 'see' the data. Huge benefits when debugging the system.

One aspect that I find missing in the other answers: enforcing semantics.

From the moment you go for human readable, you allow the silly notepad user to create data to be fed into the system. No way to guarantee this data makes sense. No way to guarantee the system will respond in a sensible way.

So in the case you don't need to notepad-inspect your data, and you want to enforce valid data (by e.g. usage of an API) rather than first validating it, you better avoid human readable data. If debuggeability is an issue (it most often is), inspection of the data can be done by using the API, too.

Answer 6

Human readable is not equal to easier to be parsed by machine code.

Take human natural language as an example. :) Machine parsing of human language is still a pending problem to be fully solved.

So I agree with https://stackoverflow.com/a/714111/2727173 which has much deeper insight on this question.