Choose by the shape of the data
JSON represents arrays, objects, strings, numbers, booleans and null explicitly. It is a natural interchange format for nested API data and settings that a program reads. CSV is a table: each record has fields in a shared column order. It is convenient for simple rows and spreadsheet imports, but a CSV cell does not inherently say whether 0012 is an identifier, a number or text. YAML is often chosen for configuration that people edit because it offers mappings, sequences and readable indentation; its parsing rules still require care. JSON Lines stores one complete JSON value per line, making a stream of records easier to append or process independently. Pick the shape the receiving software expects rather than the extension that looks most familiar.
A small example across formats
Consider the JSON array [{"id":1,"city":"Paris"},{"id":2,"city":"Lima"}]. A straightforward CSV export has a header id,city followed by the rows 1,Paris and 2,Lima. A YAML rendering can show a sequence of two mappings, each with id and city. In JSON Lines, the first line is {"id":1,"city":"Paris"} and the second is {"id":2,"city":"Lima"}; there is no outer array. The linked converters let you inspect these representations directly. Notice what happens when the city contains a comma, quotation mark or line break: CSV then needs quoting and escaping according to the reader's dialect. The short example hides that complexity, so test realistic values before exporting a large dataset.
- JSON: array of typed objects
- CSV: header plus flat rows · YAML: indented mappings
- JSON Lines: one JSON object per line
Types and nested structures need a decision
A JSON object can contain another object or an array. A conventional flat CSV row cannot express that structure without an agreed mapping, such as separate columns, a serialized JSON cell or several tables. A conversion tool must choose a policy; inspect its output rather than assuming no information was lost. Numbers and booleans may become cell text in CSV, while reading them back may require explicit type conversion. A leading zero in an account identifier is significant even if a spreadsheet wants to treat it as a number. YAML can express the same broad data model as JSON, but unquoted scalars and indentation deserve review when another parser reads the file. JSON Lines retains JSON types within each record, yet each physical line must contain one valid JSON value.
Test a round trip with representative records
Before converting the full file, make a sample containing a normal row, an empty field, a quoted field, a comma, a non-ASCII character and a nested value if your data has one. Convert it, then convert back where a reverse tool exists. Compare the structure and types, not only the visible text. Check column names, record count, ordering and whether null differs from an empty string. For JSON Lines, ensure that records are separated by line breaks and that a pretty-printed multiline object has not been mistaken for several records. The embedded JSON-to-CSV converter below starts with two simple records; change a value and examine the output. Use the other linked converters to test YAML and line-delimited paths.
Match the destination and protect imports
For a spreadsheet of uniform, flat records, CSV is often practical; document the delimiter, encoding and column types expected by the importer. When values come from untrusted people, a spreadsheet may interpret cells beginning with formula characters as formulas, so an export intended for spreadsheets needs a separate safety policy. For human-maintained configuration, YAML can be readable, but validate the result with the actual target parser. For APIs or structured documents, JSON usually exposes types and nesting more clearly. For logs and data pipelines that consume one event at a time, JSON Lines may avoid loading one enormous array. A successful syntax conversion is only the first check; the receiving program's interpretation is the decisive one.