Free · Fast · Privacy-first

Nested JSON to CSV

Modern API responses are rarely flat.

Native JSON tool

JSON to CSV

Runs in your browser
CSV output
Run the tool to see a task-specific result.

Dotted column names for nested keys

🔒

Configurable flatten depth

Optional row-explode for arrays

Preview before download

Cost
Free tier
Sign-up
Not required
Processing
Tool-specific
Privacy
Clearly disclosed
IframeResponsiveAttribution included

Add this JSON to CSV to your website

Drop the JSON to CSV into a blog post, product docs, intranet, or school portal with one iframe. Processing, privacy, and usage limits are the same as on the full tool page.

  • One copy-ready line of HTML
  • Responsive — adapts to any container width
  • No API credentials are placed in the snippet

Embed code

<iframe
  src="https://www.fixtools.io/json/json-to-csv?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON to CSV by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Flattening strategies for deeply nested JSON

The dotted-column convention is the most widely understood flattening strategy. A field at the path customer.address.city becomes a column literally named customer.address.city. Pandas json_normalize uses this convention, jq paths produce the same shape, and most cloud data warehouses including BigQuery and Snowflake accept dotted column names natively. The convention scales to arbitrary depth, which is both its strength and its weakness. A deeply nested JSON with five levels of branching can easily produce a CSV with two or three hundred columns, most of which a human reader will never look at. Flatten depth controls let you stop the recursion at a sensible level for your audience.

For a typical business-analyst audience, flatten depth 2 hits the sweet spot. Top-level fields become regular columns, one level of nesting expands into dotted columns, and anything deeper stays as a JSON-encoded cell. The analyst sees a manageable column count, the data preserved beyond depth 2 is still recoverable from the JSON-encoded cells if needed, and the CSV opens cleanly in any spreadsheet without freezing the tab. For a downstream pipeline that needs full flatness, depth unlimited is the right choice and the resulting wide CSV is still well-formed even if it has hundreds of columns.

Inner arrays are the trickiest case. The default JSON-encoded-cell behaviour preserves all information at the cost of inner data not being filterable in a spreadsheet. The row-explode mode duplicates parent fields and emits one row per inner array element, which makes filtering and pivoting easy but multiplies the row count. For an order JSON with 100 orders averaging 3 line items each, explode mode produces 300 rows instead of 100. That is usually fine for analysis but worth noting for size-sensitive use cases. If multiple inner arrays exist at the same level, exploding all of them produces a Cartesian product, which is rarely what you want, so the converter lets you pick which array to explode and keep the others JSON-encoded.

Column ordering matters for readability. The default order follows the order of first appearance in a depth-first scan of the input, which usually produces a sensible layout where parent fields appear before their nested children. The preview UI shows the column list with drag handles so you can reorder before downloading. For recurring conversions, the URL captures the active settings so a bookmark restores your preferred column order, flatten depth, and array handling on the next visit.

How to use this tool

💡

Flatten nested JSON into CSV with dotted column names. Pick a flatten depth and decide whether to explode inner arrays into multiple rows.

How It Works

Step-by-step guide to nested json to csv:

  1. 1

    Paste the nested JSON

    Paste your JSON into the editor. The parser shows the maximum nesting depth and the count of nested objects so you have a sense of how aggressive the flattening will be before you commit.

  2. 2

    Pick flatten depth

    Choose how many levels to flatten. Depth 1 flattens one level, depth 2 flattens two, unlimited flattens everything. For business audiences, depth 2 is usually the right balance between detail and column count.

  3. 3

    Decide on inner arrays

    Choose between JSON-encoding inner arrays into a single cell or exploding them into multiple rows. Explode mode duplicates parent fields and emits one row per inner item, which makes pivoting easier but multiplies row count.

  4. 4

    Reorder columns in preview

    The preview shows every detected column with drag handles. Move parent fields to the front, child fields toward the back, and exclude any internal fields you do not need.

  5. 5

    Download the flattened CSV

    Download the result and open it in your spreadsheet. The header row uses dotted notation for nested keys, and rows align cleanly across all columns regardless of which records had which nested fields populated.

Real-world examples

Common situations where this approach makes a real difference:

Engineer flattening order data for finance

A backend engineer exports orders as deeply nested JSON. Finance wants order-level totals plus customer email in a flat CSV. The engineer flattens to depth 2, which exposes customer.email and totals as regular columns while keeping line items as a single JSON-encoded cell, and finance reconciles the period in Excel without involvement from the data team.

Researcher analysing survey responses

A UX researcher has survey responses with nested demographics and a free-text comments array. They flatten demographics to depth 1 to get age, gender, and region as columns, leave comments as JSON-encoded cells for qualitative analysis, and pivot in Tableau by region in minutes.

Marketer pulling ad performance

A growth marketer pulls Facebook ad insights as JSON with nested targeting and creative metadata. They flatten to depth 3 to expose targeting fields as filterable columns, keep deep creative metadata JSON-encoded, and the marketing analyst pivots performance by audience segment in Sheets.

Operator triaging incidents

An SRE pulls incident JSON from PagerDuty with nested service, escalation, and acknowledgement objects. Flattening to depth 2 produces a flat CSV the on-call team can open in Excel during a postmortem to spot patterns by service and acknowledger.

Pro tips

Get better results with these expert suggestions:

1

Preview at multiple depths before committing

Run the preview at depth 1, then 2, then 3 and look at the column count and the human readability of each. The right depth is where the most useful fields are exposed as columns but the column count stays under about 30 for an analyst audience or under about 100 for a pipeline audience.

2

Use underscores instead of dots if needed

Some BI tools and SQL dialects dislike dots in column names because they conflict with table.column syntax. Switch the separator to underscore in the options to get customer_address_city instead of customer.address.city. This produces names that load cleanly into more downstream tools at the cost of slightly worse human readability.

3

Beware of array-of-array explosions

If your JSON contains arrays of arrays, explode mode can produce surprisingly large row counts because every level of array multiplies the rows. Check the preview row count before downloading and switch to JSON-encoded cells if the count is larger than your downstream tool can handle.

4

Cap deep nesting with summary columns

When deep nesting is mostly noise, flatten shallowly and add a downstream summary column computed from the JSON-encoded cells in your spreadsheet. This keeps the CSV human-readable while preserving the data for any audit needs.

FAQ

Frequently asked questions

Nested keys become dotted column names. The JSON object { customer: { name: "Ada" } } becomes a column named customer.name in the CSV. The flatten depth setting controls how many levels of nesting are converted into dotted columns and at what point deeper nesting stays as a JSON-encoded cell.
Depth 2 is the right default for most business audiences because it exposes enough detail without producing hundreds of columns. Depth 1 is right when you only care about top-level fields. Unlimited is right when you are feeding a pipeline that needs every field as a column. The preview lets you try several depths before committing.
You cannot selectively flatten per-field directly, but you can flatten to a chosen depth and then exclude specific columns in the preview if some flattened fields are not needed. For more targeted control, preprocess the JSON with jq to flatten only the paths you want before pasting it into the converter.
By default, arrays at any nesting level are JSON-encoded into a single cell. If you want to explode a specific array into multiple rows, the converter offers a row-explode mode that duplicates parent fields. Only one array can be exploded per conversion to avoid Cartesian-product blowups when multiple arrays exist at the same level.
Collisions are very rare with dotted column names because the full path is preserved in the column name. The only scenario where collision can happen is if the input itself has illegal duplicate keys at the same level, which violates the JSON spec and produces undefined behaviour in any parser. Run the source through a validator first if you suspect duplicates.
Yes. The options panel offers a separator setting so you can switch from customer.address.city to customer_address_city. This is useful for downstream tools that treat dots as syntax, such as some SQL dialects or BI tools where the dot is interpreted as table-column delimiter.
No. Flattening rearranges the same data into a flat schema without modifying values. Every value from the source JSON is preserved exactly in the CSV. The only transformations are structural: keys gain dot-separated prefixes, and arrays are either JSON-encoded or exploded according to your settings.

Related guides

More use-case guides for the same tool:

Ready to get started?

Open JSON to CSV to review its free limits and processing method.

Open JSON to CSV →

Free tier · No account needed · Transparent limits

Source-backed reference

JSON standards quick reference

Concise, standards-backed facts for developers working with JSON debugging and validation. Each rule links to a primary specification so it can be independently verified before you rely on it in code, documentation, or an incident report.

JSON standard
RFC 8259 defines JSON as a text format for serializing structured data. JSON values may be objects, arrays, strings, numbers, true, false, or null.
Verify in RFC 8259
Strings and object keys
JSON strings and object member names use double quotation marks. Single-quoted strings are not valid JSON syntax.
Verify in RFC 8259 §7
Trailing commas
The JSON grammar does not allow a comma after the final member of an object or the final element of an array.
Verify in RFC 8259 §4–5
Interoperability
ECMA-404 describes the JSON syntax independently of any programming language, which is why standard parsers can exchange the same JSON text across runtimes.
Verify in ECMA-404

Common invalid → valid JSON examples

Trailing comma

{"a":1,}{"a":1}

Single-quoted key

{'a':1}{"a":1}

Unsupported literal

{"score":NaN}{"score":null}

Built for verification, not just extraction

Direct answers are paired with primary sources and concrete examples. That makes this page useful to developers and also gives search and answer systems a clear, verifiable statement to reference instead of an unsupported summary.