“Flatten” gets used loosely, but it means something specific when the goal is a spreadsheet: taking a JSON structure with objects nested inside objects and turning it into a single row of columns, where every value has exactly one column it belongs in. It’s a mechanical transformation once you know the rule, but the rule is worth understanding rather than treating as a black box, especially when the source data has a shape you didn’t design yourself.
The dot-notation rule
Given a nested object like this:
{
"id": 1042,
"customer": {
"name": "Alice Chen",
"address": {
"city": "Austin",
"zip": "78701"
}
}
}Flattening walks every nested object and joins the path of keys that leads to each leaf value with a dot, producing one column per leaf: id, customer.name, customer.address.city, customer.address.zip. Every scalar value in the original document - however deeply nested - ends up as exactly one cell in exactly one column, and the column name tells you the full path back to where it came from.
This is the same rule Jsontify’s JSON to Excel and JSON to CSV converters apply automatically: paste the JSON, and every nested object flattens into dot-notation columns without any manual mapping step.
Where flattening breaks down: arrays
Objects nest cleanly because each one has a fixed, known set of keys - flattening just walks the path. Arrays don’t have that property. "tags": ["urgent", "billing"] doesn’t have an obvious column to live in, because the number of elements varies row to row, and inventing tags.0, tags.1, tags.2 columns falls apart the moment one row has ten tags and another has zero.
The practical answer - and the one used here - is to write a nested array as a compact JSON string in its one cell rather than expanding it into variable columns. It’s a deliberate trade-off: the array isn’t spreadsheet-native, but every element survives, visible in the cell if you need to check it, rather than being silently dropped or truncated to fit a fixed number of columns.
If you actually need one row per array element - for example, turning a list of order line-items into one spreadsheet row per item - that’s a different operation from flattening (it changes the row count, not just the column count), and it needs to be done deliberately based on which array in the structure should drive the row split, not applied automatically.
Column order and missing fields
When you flatten an array of objects rather than a single object, different objects in the array may have different shapes - one order has a discount field, another doesn’t. The column set is the union of every key path seen across every object, in the order each one first appears; a row missing a given field just gets a blank cell there rather than shifting every other column out of alignment.
When not to flatten
Flattening is the right move when every record has roughly the same shape and the nesting exists mostly to group related fields (customer.name, customer.email) rather than to represent a genuinely variable structure. It’s the wrong move - or at least an incomplete one - when the interesting part of the data is itself a variable-length list per record, since dot-notation columns can’t represent that without either losing information or exploding into an unpredictable number of columns. In that case, exporting the array as JSON-in-a-cell (as described above) and post-processing it separately is usually more honest than forcing a flat shape that doesn’t fit.
Trying it
Paste a nested JSON document into Jsontify and export to Excel or CSV to see the flattened result immediately - no need to plan the column mapping in advance, since the flattening rule is applied automatically and consistently. The conversion runs entirely in your browser - nothing is uploaded to our servers, so it works the same way whether the source is a sample record or a real customer export.