Choose a JSON export format

Start with the destination

Ask where the output will go first. If the next stop is Excel, Sheets, a BI import, or a database loader, use CSV or TSV and review column types during import. If the next stop is a README, issue, or report, a Markdown table or HTML table is easier to read. If the output becomes configuration, YAML, TOML, or .properties may fit better, but only after you check that the receiving application expects that structure.

JSON can nest objects, arrays, strings, numbers, booleans, and nulls in one tree. Most export formats cannot preserve that entire model without choices. The useful question is not whether a format is universally lossless. The useful question is whether the mapped output matches the job you are handing off.

Export format comparison

One input can have several useful outputs

The same source can be exported in different ways depending on what you need next. When the useful rows are wrapped inside a root object, make the selection explicit first. For a table export, the nested fields become columns such as customer.plan. For NDJSON, the shaped array becomes separate records.

{
  "orders": [
    {"order_id":"A-1001","customer":{"name":"Mina Lee","plan":"pro"},"amount":"0012.50","status":"paid"},
    {"order_id":"A-1002","customer":{"name":"Noah Park","plan":"free"},"amount":"-12","status":null}
  ]
}

.orders

[
  {"order_id":"A-1001","customer":{"name":"Mina Lee","plan":"pro"},"amount":"0012.50","status":"paid"},
  {"order_id":"A-1002","customer":{"name":"Noah Park","plan":"free"},"amount":"-12","status":null}
]

order_id,customer.name,customer.plan,amount,status
A-1001,Mina Lee,pro,0012.50,paid
A-1002,Noah Park,free,"'-12",null

{"order_id":"A-1001","customer":{"name":"Mina Lee","plan":"pro"},"amount":"0012.50","status":"paid"}
{"order_id":"A-1002","customer":{"name":"Noah Park","plan":"free"},"amount":"-12","status":null}

Export the source or a shaped result

Before exporting, decide whether you want the whole document or a smaller result. A JQ query can project only the fields you need, filter records, rename columns, or build an array that is easier to hand off. That is usually better than exporting a huge source and cleaning it later.

For row-based exports, start from an array when possible. CSV, TSV, Markdown table, HTML table, and NDJSON all depend on a row or record model. If your source is a nested object with the records buried inside, shape the desired array first with a query, then export that result.

• Shape rows with JQ examples
• See nested JSON to CSV row mapping
• See array to NDJSON record mapping

Common export pitfalls

• CSV and TSV are text formats. Spreadsheet applications may still convert values such as long IDs, dates, or negative-looking strings unless you choose deliberate import types.
• Formula-like CSV/TSV cells can be apostrophe-prefixed for safety. That includes cells beginning with =, +, -, @, a tab, or a newline, so check negative numeric text before claiming exact spreadsheet handoff.
• TOML has no null value. Mixed-type arrays are allowed by TOML 1.0, but the current exporter requires matching array value types; the TOML guide explains that separate limitation.
• Markdown table output is for tables, not arbitrary prose generation. Use HTML or CSV when rows are wide or multiline content must remain easier to inspect.
• HTML table export creates a report artifact, not a general web application. Verify the saved file, not only the workspace preview.
• NDJSON and JSONL require one complete JSON value per nonempty line. Source formatting line breaks are not record boundaries.

Export guides

Choose the detailed workflow that matches your receiving system. Each guide includes a copyable input and target output, plus the caveats that matter for that format.

• Convert nested JSON to CSV
• Convert JSON to TSV
• Convert JSON to YAML
• Convert JSON to TOML
• Convert JSON to .properties
• Convert JSON to XML
• Convert JSON to a Markdown table
• Convert JSON to an HTML table
• Convert a JSON array to NDJSON or JSONL