Data and structured data
Turn JSON into a table with CSV
Tools to use
A generated file can suggest that only the format changed. But tables and trees, text and numbers, values and comments carry different information. Error-free conversion does not guarantee that all meaning survived. Decide what must be preserved before choosing the destination format.
Start with a small JSON/CSV round trip, then inspect YAML comments and TOML's lack of null. Before converting a full business dataset, test a few records containing leading zeroes, empty strings, missing fields, and nesting to make the conversion contract explicit.
Preserving 001 does not preserve every type
[{"id":"001","quantity":2,"active":true}]CSV conversion creates id, quantity, and active columns. Converting that CSV back returns cell values as strings: 001 survives, but 2 and true are strings too. The tool does not infer types from appearance, so this round trip does not preserve the original JSON types.
[{"id":"001","quantity":"2","active":"true"}]Automatically coercing every numeric-looking cell could destroy 001 by turning it into 1. Restoring types requires column-specific rules agreed with the recipient: id is text, quantity an integer, and active a defined Boolean spelling. CSV alone cannot always recover the original types.
Null, empty text, and absence can collapse to one blank
[
{"id":"a","note":null},
{"id":"b","note":""},
{"id":"c"}
]All three note cells become blank in CSV. Converting back cannot reveal which was null, empty, or absent. Preserving that distinction needs an explicit convention such as a separate state column. Replacing every blank with null would change the meanings of the other two cases.
An update interface may interpret absence as 'leave unchanged' and null as 'clear the value'. If so, losing the distinction is significant. Check the actual importer or API before choosing which fields can travel through CSV. Do not delegate that semantic decision to a conversion button.
Store nesting in one cell or flatten it into columns?
[{"id":"a","profile":{"city":"Tokyo"}}]Reject-nesting mode refuses this conversion. Stringify mode puts profile into one cell as JSON text; flatten mode creates a column such as profile.city. Both are representations for a table, not preservation of nesting as a native table type.
The reverse conversion does not parse a JSON-looking cell back into an object or automatically rebuild profile from profile.city. Original keys containing dots also need an agreed convention. Choose the representation the recipient expects, not one that merely looks reversible.
Commas and newlines can belong inside a cell
id,note
001,"red, blue"
002,"first line
second line"This CSV has two records after the header. Splitting blindly at commas or newlines would split note contents into extra rows or columns. Inspect the table preview to confirm that red, blue is one cell and the two-line note is another. Physical line count need not equal record count.
Spreadsheet-formula neutralization adds an apostrophe to applicable cells, changing their text. Distinguish display-oriented protection from a lossless interchange representation. Tell recipients whether it was applied so they do not unexpectedly import the prefix as original data.
YAML comments do not become JSON values
# Retry only temporary failures
retries: 3
enabled: trueJSON retains retries and enabled, but not the comment. Round-tripping a configuration solely because its values convert can erase operational reasons and cautions. If comments matter, preserve the source YAML or establish another documentation policy separately from value conversion.
Refusing a conversion can be the correct outcome
TOML has no direct value corresponding to JSON null, so this converter rejects JSON containing null. Replacing it with empty text or deleting the property might create output, but changes meaning. Avoid automatic substitutions merely to make conversion succeed.
Large integers and dates also depend on destination types and implementation support. Current JSON-to-TOML conversion rejects integers beyond its exact range. When a typed date becomes JSON text, verify that its time and timezone meaning remain clear. Format names alone do not promise complete reversibility.
Use round trips to discover the contract
Compare the original and returned JSON structurally, focusing on types, nulls, absence, and nesting rather than key order. A difference is not automatically unacceptable: an intended transformation can be documented. If the loss is unacceptable, choose another format or add explicit metadata.
Record column selection, nesting mode, formula protection, and encoding choices too. Explain what was preserved and transformed instead of saying 'it came from JSON, so it is the same'. Conversion is one handoff step; the recipient must still interpret the result as intended.
Agree on empty-field meaning before exchanging data
If a CSV receiver treats an empty field as 'leave unchanged' while the sender means 'delete the value,' processing can disagree without any encoding or syntax error. Define empty string, null and unspecified before flattening the data. An explicit state column or a different exchange format is a contract decision. Producing a valid file and sharing its meaning are separate checks.