Tested guide
What happens to duplicate keys when you format JSON?
See a repeated key disappear, integer-like keys move, and whitespace change.
In JavaScript, JSON.parse retains the last value for a repeated object key. JSON.stringify cannot restore earlier values. It can also change whitespace and the order of integer-like property names. Formatting a parsed object is not a lossless rewrite of the original JSON text.
The experiment
| What we tested | Input text | Native parse → stringify |
|---|---|---|
A repeated object key | {"role":"reader","role":"editor"} | {"role":"editor"} |
Integer-like object keys | {"2":"two","1":"one","b":true} | {"1":"one","2":"two","b":true} |
Computed from the published fixtures using Node.js 22.22.2, ICU 78.2, Unicode 17.0. Run the same examples in your browser.
A valid parse can still discard information
In our repeated-role example, the original text contains both reader and editor. The parsed object has one role property with the value editor. The output looks tidy, but one occurrence has disappeared. This tool does not currently flag duplicate keys before parsing.
RFC 8259 says object member names should be unique and describes interoperability problems when they are not. Other software can reject duplicates or handle them differently. Treat duplicate keys as a producer-side data problem instead of depending on a particular parser to resolve them.
Property order is not a signature contract
The second example writes key 2 before key 1. Native serialization prints the integer-like keys in ascending order in this case. Other string keys follow their applicable property-order rules; ordinary formatting is not alphabetical sorting.
Systems that sign or hash serialized documents need a defined canonicalization procedure or the untouched original bytes. Two texts can describe equivalent data while producing different hashes. Neither indenting nor removing spaces makes arbitrary JSON suitable for cryptographic signing.
A safer review workflow
Keep the raw input, inspect suspicious repeated fields in an editor, and ask the producer which value was intended. For trusted test data, compare the formatted output with the original before using it downstream.
Use the formatter for readability and syntax checks. Use a schema validator for field requirements and an appropriate duplicate-aware parser when duplicates must be rejected. Our tool does not establish business correctness or authenticity.
Standards and references
These results describe the tested implementations and inputs. Report a reproducible discrepancy through our contact page.
Continue exploring
Why JSON formatting can change large numbers ↗
A reproducible example of a 17-digit ID changing during parsing, and when to use a string.
What happens to duplicate keys when you format JSON? ↗
See a repeated key disappear, integer-like keys move, and whitespace change.