Fully agree, the human readability of json and xml is &quot;fake productivity&quot;, it tricks you into thinking the format is easy and invites you to do hacks like manually writing the serialization and only helps you short term.<p>I&#x27;ve worked in places where binary serialization + deserialization functions were generated automatically by just adding a field and the bit-mapping into a message-spreadsheet. This was way more productive than misspelling the property name of a json-field between serializing and de-serializing and spending a whole day troubleshooting that. This also automatically documented the format instead of sending an example xml-file to your counterpart who is to implement loading of the data elsewhere and saying &quot;the data will look aproximately like this&quot;. Viewing the data for debugging was done with a special program (similar to wireshark) that understood the protocol and rendered a much nicer view of the data than pasting a json-file into notepad++, there you need indentation and highlighting plugins anyway so the number of programs you need installed is not an argument either, streaming data through notepad++ doesn&#x27;t work so well either if you want to view data on the fly.<p>Security is also one aspect, at every place i&#x27;ve worked there is always one smartass that thinks xml can be created by string-concating, that&#x27;s impossible if the serialization-functions are totally encapsulated.<p>All this isn&#x27;t a problem inherent to xml&#x2F;json as it can all be solved with proper processes, it&#x27;s just that it invites to that type of culture.