Flatten JSON Online

Flattening rewrites a nested JSON document as a single flat object whose keys are the full path to each leaf value. Instead of walking through nested braces, you get one entry per scalar: a string key like user.address.city and the value that lives at that path. The depth that was expressed by nesting moves into the key names, so the document loses its levels but keeps every value.

The path syntax is called dot notation: each level of an object is joined to the next with a dot, so { "a": { "b": 1 } } becomes { "a.b": 1 }. It is the same convention many libraries already use to reach into nested data — Lodash's _.get(obj, 'a.b.c'), MongoDB's dotted field queries, and countless config systems all address nested values by path. Flattening simply materializes every one of those paths at once.

The transform is deterministic — the same input always produces the same output — and JSON Copilot runs it as plain code on its own server, so no AI model is involved and your JSON never reaches an LLM. It is lossless for values and, for plain object and array data, largely lossless for structure too: given the flat keys you can usually reconstruct the original nesting. The caveats to that round trip are covered below.

Objects nest by name, but arrays nest by position, so flattening records array elements with a bracketed index instead of a dot: orders[0].total, orders[1].total, and so on. The index is zero-based, matching JSON and JavaScript semantics, and it is appended directly to the key that holds the array. An array of objects therefore produces keys like items[0].sku and items[1].sku.

Nested arrays extend the same idea by chaining brackets: a two-dimensional matrix flattens to matrix[0][0], matrix[0][1], and matrix[1][0]. Mixed nesting — an array inside an object inside an array — reads left to right along the path, for example data.rows[2].cells[0]. Because every segment is explicit, no positional information is lost and the flat keys sort in a predictable order.

Empty containers are the one place implementations differ. A leaf that is an empty object {} or empty array [] has no scalar inside it to emit, so some flatteners drop the path entirely while others keep a single key mapped to the empty value. If preserving empty structures matters for your round trip, verify that behavior against your own data before relying on it.

The most common reason to flatten is tabular export. Spreadsheets and CSV files are inherently flat — one column per field — so a nested API response has to be collapsed before it fits. Flattening turns user.address.city into a column header and its value into the cell beneath it, letting you paste an array of records straight into Google Sheets or Excel.

Flat key/value pairs also map cleanly onto configuration and environment systems. Tools that read delimited keys — application.properties files, feature-flag stores, or key/value databases — accept a flattened document with little translation, and environment variables usually swap the dot for a double underscore, as in USER__ADDRESS__CITY. The same shape makes config diffing far easier: comparing two flat documents surfaces exactly which paths changed instead of a noisy diff over reindented nested blocks.

In analytics, flattening is a stepping stone to columnar storage. Warehouses such as BigQuery can query nested and repeated fields directly with UNNEST, but many pipelines still flatten JSON first so each path becomes its own typed column that is simple to select, filter, and aggregate. Flattened logs and events are likewise easier to index in search engines and to feed into tools that expect a single field per key.

Because the keys carry the full path, a flattened document can usually be expanded back into nested JSON: split each key on its dots and brackets, then rebuild the objects and arrays segment by segment. Value types survive the trip, so numbers stay numbers, booleans stay booleans, and null stays null — nesting is the only thing that changes.

The round trip is not always unambiguous, though. If an original object key literally contains a dot — {"user.name": "Ada"} — a naive unflattener reads it as two levels (user then name) and rebuilds the wrong shape. Keys that contain brackets, or numeric object keys that look like array indexes, create the same confusion, and sparse or reordered arrays can lose information when indexes are missing.

Types only survive as long as you stay in JSON. Exporting the flat result to CSV is a different matter: every value becomes text, so 42 and "42" are no longer distinguishable and null collapses to an empty cell. For that reason, treat flattening as a one-way transform for display and export, and keep the original nested JSON whenever you need a guaranteed, loss-free round trip.