Data & spreadsheets · CSV Cleaner
CSV vs JSON: Two Data Formats and the Ideas About Structure Behind Them
· Background
csv json data-formats
CSV describes a table; JSON describes a tree. This post explains where JSON came from, why it carries types and nesting that CSV cannot, and what the mismatch means every time data moves between the two.
The same customer list looks completely different as CSV and as JSON — why each format encodes a different idea of structure
A customer table looks compact in CSV because each row borrows meaning from one shared header. JSON repeats property names in each object and can nest an address or list beneath a customer. The two files therefore express different structural capabilities even when their visible facts overlap.
ToolAcre converts the common intersection: a flat header plus data rows becomes a top-level array of flat objects. It does not turn punctuation in headers into branches or infer arrays from repeated columns. Understanding that boundary prevents a flat converter from being mistaken for a data-model designer.
CSV as a grid — rows and columns, positional meaning, and nothing beyond text
Within this implementation, CSV is a rectangular table of strings. The first row supplies header names and each later cell receives meaning from its column position. Short rows are padded and long ones warned about, because position only works reliably when row width agrees with the header.
There are no native number, boolean, object or null cells. Quotes protect syntax but do not assign type. A digit sequence and the word true remain textual values, which keeps identifiers stable and asks the consumer to apply a schema where one actually exists.
In ToolAcre, CSV cells are strings positioned under one header row
The workbook asks for JSON’s early-2000s origin and standards history, but this repository is not a source for those dates or publications. The verifiable behavior is that the browser uses `JSON.parse` and `JSON.stringify`, accepting a top-level array of objects for conversion to a table.
Invalid JSON receives a specific parse error, a non-array root is rejected, and arrays containing primitives are unsupported. Those runtime boundaries matter more to a visitor than an uncited chronology. Historical context should come from primary standards outside this task’s source set.
JSON standards history is outside repository evidence; the supported runtime shape is verifiable
A JSON object carries each key beside its value, while a CSV cell relies on the header at the same index. ToolAcre computes disambiguated keys once, then maps every row by position. Missing represented cells become empty strings so objects share a stable key set.
That self-description has a size and repetition cost but makes each JSON record understandable without separately locating a header. Conversely, changing a CSV column order without its header destroys meaning. Conversion must keep names and positions paired throughout the table.
Trees versus tables — nesting, arrays and optional keys, and why they have no natural place in a row
JSON values can contain objects and arrays, while one CSV cell cannot natively branch. In the reverse direction ToolAcre serializes a nested value with `JSON.stringify` and places that JSON text in one cell. It does not create address_city columns or additional tag rows.
Optional keys across JSON records become the union of columns in first-seen order, with blanks where an object lacks a key. That is a defensible flattening for sparse flat objects. It does not provide a natural mapping for arbitrary trees, and the route says so rather than guessing.
Worked example — one record with a nested address and a list of tags, shown in JSON and then forced into CSV columns
A flat CSV row `id,name,city` followed by `001,Ada,London` converts cleanly to one object with three string properties. If the JSON instead contains `address: {city: "London"}` and `tags: ["math","code"]`, reverse conversion writes those nested values as JSON strings under address and tags columns.
Loading that CSV again yields strings containing JSON syntax, not reconstructed nested values. A later application could parse those cells under its own schema, but ToolAcre does not. The worked comparison isolates exactly where table structure ends and tree structure begins.
Worked example: flat fields convert directly, while nested JSON is preserved only as cell text in reverse
JSON Lines, schema languages and streaming parsers are outside the implementation. Output is one indented array, and file input is read into memory before conversion. Do not infer record-by-record streaming from the presence of a parsing worker.
Likewise, the tool does not validate required properties or numeric ranges. It protects object keys from blank and duplicate headers and reports row shape, but semantic correctness remains a consumer responsibility. Flat syntax can be valid while business data is wrong.
Know which structure you are moving towards — how the ToolAcre CSV Cleaner converts flat tabular data between CSV and JSON
Know which structure the destination expects. For flat exports, ToolAcre gives a transparent bridge: headers become unique keys, rows become objects and values remain strings. For nested application models, define a mapping rather than forcing branches through accidental column naming conventions.
Preview the table, resolve ragged rows and inspect generated JSON before download. The converter is strongest when used within its narrow intersection of the formats. It does not erase their conceptual difference, and a trustworthy workflow should not ask it to.