JSON Objects
JSON objects are unordered name/value pairs. Learn how duplicate keys actually behave, how nesting works, and practical patterns for structuring object data.
Try It Now
Put this into practice with OpenFormatter's free tools — no signup, 100% client-side.
Specification: RFC 8259 doesn't forbid duplicate names within an object — it says names SHOULD be unique, not MUST — but it explicitly warns that receiver behavior is unpredictable when they aren't. Some implementations report only the last name/value pair, some report an error, and some report all of the pairs including duplicates. Don't rely on any of those three behaviors matching what a different parser will do.
Important: Don't write code whose correctness depends on the order JSON object keys appear in. The specification defines objects as unordered; a parser that happens to preserve insertion order today isn't guaranteed to keep doing so, and a different parser may not preserve it at all.
Definition
A JSON object is an unordered collection of name/value pairs — RFC 8259 is explicit that ordering isn't guaranteed, even though some parsers happen to preserve insertion order in practice. Code that depends on a specific key order for correctness is relying on implementation behavior the spec doesn't promise, not a guarantee.
Every value in an object can itself be any JSON type — a string, number, boolean, null, another object, or an array — which is what makes nesting possible. There's no depth limit in the grammar itself; practical limits come from parsers, memory, and readability, not the specification.
Examples
A flat object — every value is a primitive.
{
"id": 482,
"name": "OpenFormatter",
"active": true
}A nested object — values can be objects or arrays, to any depth the grammar allows.
{
"id": 482,
"name": "OpenFormatter",
"pricing": {
"free": true,
"plans": ["free", "pro"]
}
}Duplicate names are not forbidden by the grammar, but what a parser does with them is unpredictable — this is exactly the case the specification callout above describes.
{ "tag": "json", "tag": "data-format" }
// A parser might return "data-format" (last wins), throw an error,
// or return both -- RFC 8259 doesn't say which.Common Mistakes
Using duplicate object keys to represent multiple values for one field
Repeating a key (e.g., { "tag": "a", "tag": "b" }) to mean "both values apply" relies on unpredictable parser behavior — RFC 8259 gives no guarantee that both survive.
Fix: Use an array value instead: { "tag": ["a", "b"] }. Arrays are the correct JSON structure for an ordered collection of values under one key.