A JSON object can be written with the same member name more than once, but interoperability guidance says names should be unique. Different parsers may keep the first value, keep the last, report an error or expose every pair. That inconsistency makes duplicates dangerous at security and data boundaries.
The parser decides what survives
JavaScript JSON.parse normally keeps the last occurrence, so parsing {"role":"user","role":"admin"} produces an object whose role is admin. By the time a reviver runs, the earlier value is no longer visible.
Other languages, streaming parsers and validation tools may behave differently. Two services can therefore interpret the same wire document as different logical data even though both claim to support JSON.
JSON.parse('{"role":"user","role":"admin"}')
// { role: "admin" }Why duplicates become a security problem
A gateway might validate the first value while an application uses the last, or a signature system might canonicalize members differently from the consumer. Attackers can exploit disagreement when a duplicated field controls identity, authorization or routing.
The safe rule at an untrusted boundary is to reject duplicate member names before converting the document into an ordinary map or object. That requires a parser mode that reports member events or explicitly detects duplicates.
Formatting cannot recover lost values
A formatter built on JSON.parse will display only the value its parser retained. The output may look clean while hiding the fact that the source contained duplicates. Run duplicate detection on source tokens before ordinary parsing when provenance matters.
Structural comparison after parsing has the same limitation. Keep the original bytes for audit purposes and make duplicate-name checks part of ingestion, not a later cleanup step.
Prevent duplicates at the producer
Serialize from a well-defined object model instead of constructing JSON with string concatenation. When merging objects, define collision behavior and test it. Schema validation alone may not catch source duplicates if the validator receives an already-parsed object.
Include duplicate-key fixtures in parser compatibility tests. A deliberate rejection is easier to operate than silent, implementation-dependent acceptance.
Practical takeaways
- Object member names should be unique.
- JSON.parse keeps the last duplicate value.
- Detect duplicates before ordinary object parsing.
- Reject ambiguous input at trust boundaries.
How this guide was prepared
JSON Anvil guides are written for working developers, checked against reproducible examples, and reviewed for technical clarity. Tool output is tested locally; readers should still validate behavior in the exact runtime used by their application.