JSON to CSV vs CSV to JSON The Data Conversion Round Trip — What Gets Lost When You Convert Between Formats and Why the Original Is Always Better

You receive a JSON file from an API: 2,000 customer records, each with nested objects (address, preferences, order history) and typed fields (dates, numbers, booleans). You need to analyze the data in Excel. Excel does not read JSON natively. You use a JSON to CSV converter to flatten the JSON into a CSV file. The CSV opens in Excel. You analyze the data. You make changes. You convert the CSV back to JSON with a CSV to JSON converter. The round-trip JSON looks different from the original. The nested objects are gone — flattened into dot-notation keys. The types are gone — everything is a string. The arrays are gone — converted to comma-separated strings. The round trip was lossy. Information was destroyed in both directions.

Here is exactly what gets lost when you convert between JSON and CSV — and why the original JSON is always better than the round-tripped version.

JSON → CSV: What Gets Lost

Nested objects: JSON supports nested structures — objects within objects, objects within arrays. CSV is a flat table — rows and columns. Nested objects are flattened using dot notation: {"user": {"name": "John", "address": {"city": "NYC"}}} becomes columns user.name and user.address.city. The structure is represented. The hierarchy is lost. You cannot reconstruct the original nesting from the flattened keys — the converter guesses at the structure, and the guess might be wrong.

Arrays: JSON supports arrays — ordered lists of values. CSV does not. Arrays are converted to comma-separated strings: [1, 2, 3] becomes "1,2,3". The array is represented as a string. The types of the elements are lost. The array structure is lost. You cannot reconstruct the original array from the string — the converter does not know whether "1,2,3" was an array of numbers or a single string that happens to contain commas.

Data types: JSON has types — strings, numbers, booleans, null. CSV has no types — everything is a string. 42 becomes "42". true becomes "true". null becomes "" or "null". The type information is lost. When you convert back to JSON, the converter must guess the types. The guess is based on heuristics — if a value looks like a number, it becomes a number. The heuristic is usually correct. When it is wrong, the data is corrupted.

CSV → JSON: What Gets Added (That Was Not There Before)

The CSV to JSON converter makes assumptions about the data: every row becomes a JSON object, the first row is assumed to be headers, and all values are strings unless the converter infers types. The assumptions are usually correct. When they are wrong: the first row was not headers but data — the converter used the data as keys, and the actual data is lost. A column contained mixed types — some numbers, some strings. The converter inferred the type from the first value and mishandled the rest. A column contained empty values — the converter converted them to empty strings, null, or omitted them entirely, depending on the converter's configuration.

The Golden Rule of Data Conversion

Always preserve the original JSON. The CSV is a working copy for analysis. The original JSON is the authoritative version. The round trip is lossy. The original is lossless. When you need to edit the data, edit the original JSON — not the CSV. The CSV is for reading. The JSON is for storing. Confuse the two, and you will lose data in the conversion.

Convert at JSON to CSV for analysis and CSV to JSON for API compatibility. But always keep the original JSON. The round trip is lossy. The original is the truth.