How to use this JSON Flattener
You do not need to install anything or write a script to flatten JSON. Paste your nested
JSON into the input area, choose how array indexes should appear, choose your preferred key
separator, and click Flatten JSON. The result is generated instantly in
the output box.
- Paste valid JSON into the input field.
- Select your preferred array key style.
- Choose a separator such as dot, underscore, or slash.
- Click Flatten JSON.
- Review the flattened output.
- Copy the result or download it as a JSON file.
If your JSON is invalid, the tool will show an error message so you can correct the input.
If you want to verify syntax first, try our
JSON Validator. If you want the original structure to be
easier to read before flattening it, use the
JSON Formatter.
Example input
{
"user": {
"name": "John",
"profile": {
"city": "London",
"active": true
}
},
"skills": ["json", "api"]
}
Example output
{
"user.name": "John",
"user.profile.city": "London",
"user.profile.active": true,
"skills[0]": "json",
"skills[1]": "api"
}
The separator collision that makes flattening ambiguous
Flattening turns a path like user.profile.city into a single key, and that
works right up until one of your real keys already contains the separator. If your data has
a top-level key literally named example.com — common in metrics, DNS records,
feature-flag maps, and analytics dimensions — then the flat key example.com is
indistinguishable from a nested example → com. The path has become
genuinely ambiguous, and no reader can recover which one you meant.
This is why separator choice is not just cosmetic. Dot notation collides with domain-like
and version-like keys; underscore collides with the many keys that already use underscores;
slash collides with paths and URLs. There is no separator that is safe against all possible
data, so pick the one least likely to appear in your keys, and be aware the risk
never fully disappears.
Flattening is not reversible for free
A flat key-value map looks like it should un-flatten cleanly, but two kinds of information
are lost in the process. First, array indices and numeric object keys become
indistinguishable: a flat key items.0 could mean the first element of an array
or an object with the string key "0". Without a rule that says which,
reconstruction has to guess, and JSON allows both.
Second, empty containers vanish. An empty object {} or empty array
[] has no leaf values inside it, so it produces no flat key at all, and
un-flattening cannot know it was ever there. If a downstream system distinguishes "field
absent" from "field present but empty", flattening erases that distinction. Treat flat
output as a lossy view for inspection and transport, not a guaranteed round trip.
Arrays, index notation, and the sparse-column trap
Arrays need index notation to flatten — either bracket style items[0].name or
dot style items.0.name — and this tool offers both so you can match your
codebase or analytics platform. The catch appears when you flatten an array of objects with
the intent of building columns. Records of different lengths produce different sets of
indexed keys, so one row has tags.0 through tags.2 and the next
only tags.0. Line them up as a table and you get a sparse, ragged grid where
most cells are empty.
For that reason, flattening arrays-of-objects is usually the wrong step before a CSV export;
it is better suited to inspecting or diffing a single nested document than to tabularising a
collection.
How null and empty values behave
A null is a real leaf value, so it keeps its path and appears in the flat
output as path: null — distinct from a key that is simply missing. Empty
objects and empty arrays, as noted above, are the ones that disappear because they contain
nothing to attach a path to. Knowing this pair of behaviours tells you exactly what a round
trip through flattening will and will not preserve.
Validate structure first with the JSON Validator, and if
you only need a few specific values rather than the whole tree, the
JSON Path Evaluator extracts them without flattening
everything.
Frequently asked questions
What happens if a key already contains the separator?
It becomes ambiguous. A top-level key named example.com flattens to the
same example.com as a nested example → com, and
nothing can tell them apart afterwards. Pick a separator that does not appear in your
keys, though no choice is safe against every dataset.
Can I reliably un-flatten the result?
Not without a convention. A flat key like items.0 could rebuild as an
array element or as an object with key "0", and empty objects and arrays
leave no trace to restore. Flattening is a lossy, one-way view unless both sides agree
on exact rules.
How are arrays represented?
With index notation — either items[0].name or items.0.name,
your choice. Be careful flattening arrays of objects for a spreadsheet: records of
different lengths create different indexed keys and produce a sparse, ragged table.
What happens to null and to empty objects or arrays?
A null is a leaf, so it keeps its path and shows as path: null.
Empty objects and empty arrays contain no leaf, so they produce no key and effectively
disappear — which erases any "present but empty" versus "absent" distinction.
Which separator should I choose?
Match whatever your consumer expects — analytics tools often want dots, some databases
prefer underscores. The deciding factor is which character is least likely to occur
inside your own keys, because that collision is what breaks the paths.
When should I keep JSON nested instead?
Keep it nested whenever the structure carries meaning your consumer relies on — arrays
whose length matters, empty containers that signal state, or data you will later
un-flatten. Flatten for one-off inspection, diffing, and search, not as a permanent
storage form.