JSON Flattener

Nested JSON models relationships: this address belongs to this customer, these totals belong to this order. It is the right shape for transmitting a record, because the structure carries meaning. Flat JSON models lookups: given a path, find a value. That is the right shape for translations, feature flags, and configuration, where consumers ask for one specific setting and never care about the tree. Neither is better — the useful question is whether the data is being read as a whole or queried one key at a time.

One underrated use is comparison. Two nested documents that differ in a single deep value produce a diff cluttered with context lines and indentation, and locating the actual change means counting braces. Flatten both first and every line becomes a complete path with its value, so the difference is a single differing line with the full route to it spelled out. Combine it with key sorting and comparing two API responses or two configs becomes almost trivial.

Any system that wants a flat map rather than a tree. Translation and localisation files are the classic case — i18n libraries commonly key strings by paths like checkout.payment.errors.declined. Environment configuration is another, since environment variables cannot nest. Beyond that, flattening is genuinely useful for diffing: a flat list of full paths shows at a glance which leaf values two documents disagree about, without the indentation noise that makes nested diffs hard to read.

Elements are keyed by their index, so items.0.sku is the sku of the first element. That preserves the data faithfully and keeps the round trip unambiguous, but it does mean flattened arrays are fragile as configuration: inserting an element at the start renumbers everything after it, so any key you referenced elsewhere now points at different data. If your array is really a set of named things, consider keying it by id in the source rather than flattening positions.

The paths contain everything needed to rebuild it, and unflattening is straightforward in most languages — libraries like lodash offer it directly. The one thing that cannot survive the round trip cleanly is a literal dot inside a key name, because it becomes indistinguishable from a path separator. If your keys can contain dots, flattening with a delimiter that cannot appear in your data is the safer approach.

When the nesting is doing useful work. Flattening makes leaf values easy to reference but throws away the grouping that tells you which fields belong together, and it makes structural operations awkward — deleting a whole subtree becomes deleting every key with a matching prefix. It also does not suit repeated records: flattening a list of a thousand users produces thousands of numbered keys, where the array was the clearer representation.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.