Convert CSV and JSON

Choose the format the destination can actually use

Use Table to JSON when you have rows and columns and a receiving application expects an array of objects. Each row becomes one object and the header names become its keys. Use JSON to table when you have an array of flat objects and a person or import process needs rows instead. If you only want to switch delimiters, keep the table and use the CSV and TSV converter; going through JSON is unnecessary.

Begin with a small complete sample. Include the header, a normal record and a record with a blank or quoted field. Choose the delimiter from the actual source. CSV usually uses commas, but semicolons and tabs are common in exported or pasted data. If an apparent CSV header becomes a single JSON key containing multiple names, the delimiter may be wrong even if the conversion produces syntactically valid JSON.

Save the original separately before trying the reverse conversion. A row of strings and a JSON object with typed values are not equivalent in every context. Converting back does not reliably restore value types or distinguish null from a missing field. Use the two directions to produce the representation the recipient needs, not as a general-purpose serialization format for preserving every detail.

Use headers that identify one field each

Paste this sample in Table to JSON with a comma separator. The first line supplies three property names. A quoted comma belongs to the city value, and the leading zeros belong to the code, not to the presentation of a number.

code,city,note
    0017,"Portland, OR",Ready
    0042,Leeds,

The first result object has the code string "0017" and the city string "Portland, OR". The empty note in the second row becomes an empty string. If you remove the last comma from that row, it has fewer fields than the header and the converter should report the mismatch. That is not the same as intentionally writing an empty last field.

A header must provide nonempty, distinct names. Two headings called id cannot tell the recipient which column represents a supplier and which represents a product. Rename them to distinguish their roles before conversion. Keep a mapping if the receiving system expects specific keys, and check their exact casing. If the source does not have headers, add one deliberately rather than letting the first record be interpreted as names.

Treat CSV fields as strings until you know their intended types

The text 0017 may be an order number, a reference code or a number displayed with leading zeros. The converter does not decide which. In Table to JSON, fields remain strings. This preserves the visible text and prevents a blank value from being silently recast as zero, null or a missing key. It also means that the word false becomes a string, not a Boolean, and the text 12.5 does not become a numeric value.

Check the application's schema before importing. If it expects a number in a particular column, convert that column deliberately with the receiving tool or a type-aware transformation. Test a valid value, a blank value and an unusual spelling. Do not change types globally just because many fields happen to look numeric. The receiving application may apply automatic conversion even when the JSON string is correct, so inspect the actual imported value.

The JSON formatter is useful for reading the output or checking syntax after an edit. It does not check the destination's schema. Compare the first and last record and look for values whose type matters, especially identifiers, dates, flags and decimal values. A valid array can still be the wrong shape for an API that expects an enclosing object.

Flatten nested data before making a table

JSON to table expects an array of objects with simple values. An object that contains a list of tags or another object does not map unambiguously to one cell. A nested address might need separate street and city columns, while a product with multiple tags might need a separate related table. The converter rejects nested values rather than choosing a flattening rule for you.

Decide how much of the structure the destination needs. If a reader only needs a few fields, create a separate flat excerpt with those fields and keep the original JSON. If a program needs all the relationships, keep the JSON or choose a format designed for that structure. Joining nested values into one string may be readable, but the resulting file will not reliably reconstruct the original object or list.

When reviewing a flat export, check what happens to fields that are present only in some records. This converter includes columns from the set of records, not just the first object. A missing field and a null both leave a blank table cell. If your application distinguishes them, do not use the table as the only retained version. Label the output a review export or use an explicit representation that your recipient has agreed to interpret.

Check quoting, line breaks and spreadsheet behavior

A CSV field can contain a comma, a double quote or a line break. The field must be quoted appropriately so a table reader can tell where it ends. When converting JSON to a table, this tool quotes values as needed for the output separator. Visible quotation marks in the file are often part of the representation, not changes to the cell content. Check the values in an importer that supports your selected delimiter before comparing results.

Be cautious with spreadsheet applications. They can interpret an identifier as a number, a date-like string as a date, or certain leading characters as a formula. Delimiter quoting is not a guarantee that a cell will be treated as literal text. If the data is untrusted or exact spelling is important, choose the import options that preserve text and inspect a small sample first.

For multiline source cells, compare record counts rather than just counting the displayed lines. A quoted cell can span several lines and still belong to a single record. If you want a table for a document rather than an import, try CSV to Markdown on a separate sample. A preview table can be shortened; the source intended for import should preserve the necessary records.

Verify one representative record and explain what cannot round-trip

Choose a typical record, a row with an empty value, a long ID and a value with punctuation. Convert them, open the result where it will be used and compare the actual fields with the originals. Confirm that headers map to the intended properties and that a missing value was not mistaken for an absent record. A good check looks at both representation and meaning, not simply whether the file opened.

If you convert a flat JSON sample to CSV and back, expect string fields on the return. Booleans and numbers from the source will not automatically regain their original types. Null and missing properties cannot be recovered just from a blank cell. For a workflow that depends on such distinctions, use a format or import configuration that carries explicit type information. Preserve the source JSON until the destination result has been checked.

Write down the delimiter, whether a header is present and any assumptions about blanks or identifiers. Give the recipient a tiny example of the expected shape if the export is being automated. The structured text guide covers the broader workflow for making one version for software and another for documentation. Both can be useful without pretending they are interchangeable.

Export long numbers and catch duplicate keys

Try [{"id":9007199254740993,"amount":0.1234567890123456789}] in JSON to table. Both cells keep every digit as written. A value such as 1.2300e+3 keeps its trailing zeros and exponent notation. In the other direction, Table to JSON writes the same cells as strings. Neither direction can recover digits if the system that created the input rounded the value before you copied it.

If a record contains "label":"first","label":"second", export stops and identifies the repeated key and the record number. Rename one field if you need both values, or choose which value to keep. The same key in different records is expected: those cells belong to the same column.

To verify exact values, open the downloaded CSV in a text editor first. If a spreadsheet is the destination, import the long-ID column as text and compare it with the CSV before saving. A spreadsheet can still round numbers or change their display when it imports them.