Free · Fast · Privacy-first

Flatten Nested JSON to CSV

When you want every leaf field of a nested JSON to become its own CSV column, you want a full flatten.

Native JSON tool

JSON to CSV

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

Full recursive flatten

🔒

Dot or underscore separator

Handles arrays gracefully

Configurable max depth

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.

How recursive flattening works in practice

The flatten algorithm walks the JSON tree depth-first. Each leaf value (a string, number, boolean, or null) becomes a CSV cell, and the column name is the path from the root to the leaf, joined with the chosen separator. The path { customer: { address: { city: "London" } } } produces a column named customer.address.city with the value London. This convention scales to arbitrary depth and is the same approach used by pandas json_normalize, jq path expressions, and most data warehouses.

Arrays are the interesting case. When an array contains primitives, the array becomes a JSON-encoded cell by default, preserving the values without exploding the row count. When an array contains objects, you have a choice: JSON-encode the whole array as a cell, explode each element into a separate row by duplicating parent fields, or include only the first element flattened with an index suffix. Each choice has trade-offs. JSON-encoding preserves information but is opaque to spreadsheets. Exploding produces analyst-friendly rows but multiplies row count. Index-suffixing produces a fixed-width row at the cost of dropping array elements beyond the first.

Maximum depth is the dial that prevents column explosion. A JSON tree with five levels of branching, three keys per level, produces 243 leaf paths if all branches are present. Most analysts get overwhelmed by more than 50 columns. Capping depth at 2 or 3 produces a manageable column count while preserving the most-used fields, and remaining depth stays as JSON-encoded cells that can be re-parsed if needed. FixTools shows the projected column count for each depth setting so you can pick the right one before downloading.

Underscore vs dot separator is mostly a downstream-tool consideration. Dots are more readable for humans but conflict with some SQL dialects where dot is the table-column separator. Underscores are uglier but universally accepted in column names. If your downstream is BigQuery or Snowflake, dots work fine. If your downstream is older Postgres or MySQL, switch to underscores to avoid quoting issues.

How to use this tool

💡

Recursively flatten nested JSON into a wide CSV with one column per leaf field, using dot or underscore separator.

How It Works

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

  1. 1

    Paste JSON

    Paste your nested JSON. The parser shows the maximum nesting depth and projected leaf-field count.

  2. 2

    Pick max depth and separator

    Choose how deep to flatten and whether to join with dots or underscores. The projected column count updates so you can pick a manageable width.

  3. 3

    Choose array handling

    Decide whether arrays JSON-encode, explode into rows, or index-suffix into separate columns. Each has trade-offs explained in the panel.

  4. 4

    Preview and download

    Inspect the preview. If the column count is too high, lower the depth. If the row count is too high after exploding, switch arrays back to JSON-encoded cells.

Real-world examples

Common situations where this approach makes a real difference:

Pipeline feed for BigQuery

A data engineer flattens nested JSON fully so the resulting CSV maps directly to BigQuery columns. Dot separator works because BigQuery handles dotted column names natively.

Analyst pivot in Sheets

A marketing analyst flattens to depth 2 to expose the most useful fields as filterable columns while keeping deep noise as JSON-encoded cells. The analyst pivots in Google Sheets without column-count overwhelm.

Survey response analysis

A researcher flattens nested demographics and exploded option arrays so each response becomes one row per selected option. This shape lets them pivot by option in Excel directly.

Migration to relational schema

A database engineer flattens JSON to depth-3 for a one-time migration into Postgres. Underscore separator avoids dot-quoting issues in the SQL bulk-load step.

Pro tips

Get better results with these expert suggestions:

1

Project column count before flattening

The converter shows the projected column count for each depth setting. Pick the lowest depth that still exposes the fields your audience needs, to keep the CSV readable.

2

Avoid full flatten for opaque metadata

If your JSON contains opaque metadata blobs (like internal version, hashes, audit fields), full flatten produces noise columns. Cap depth above those fields or exclude them in the preview.

3

Pair explode with row-limit safeguards

Exploding arrays multiplies row count by array length. Check the projected row count before committing, and switch to JSON-encoded cells if the count exceeds what your downstream tool can handle.

4

Use underscore for non-modern SQL

BigQuery and Snowflake handle dotted column names. Older Postgres, MySQL, and Oracle versions need underscores or careful quoting. Switch the separator early to avoid downstream rework.

FAQ

Frequently asked questions

Dot is the most readable and matches conventions in pandas, jq, BigQuery, and Snowflake. Underscore is uglier but works in any SQL dialect. Pick dot unless your downstream tool has issues with it.
Depth 2 is a good default for analyst audiences. Unlimited is fine for pipeline feeds where every leaf field needs to be a column. Test in the preview to see the projected column count at each depth.
Arrays JSON-encode into single cells by default. Optionally, they can explode into multiple rows or index-suffix into separate columns. Pick based on your downstream tool's preferences.
Not directly. The depth setting applies uniformly. For per-key control, preprocess the JSON with jq to flatten specific paths, then use no-flatten mode in FixTools for the rest.
No. Values are preserved exactly. Only the structure is rearranged. The flattened CSV is a lossless representation of the source JSON within the chosen depth.
A leaf object (one containing only primitive values) flattens to one column per child key. A truly empty object becomes a column with an empty cell. The converter handles both cases without surprises.
Yes, using the FixTools CSV to JSON converter with the unflatten option. Dotted column names reconstruct into nested objects, recovering the original structure. The round-trip is exact for any JSON that did not have illegal duplicate keys.

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.