JSON Objects: Key-Value Mapping and Serialization rules

The syntax

A JSON object is an unordered set of key-value pairs wrapped in {}, keys always double-quoted strings, values any of JSON's six types:

{
  "id": 42,
  "name": "ToolSphere",
  "active": true,
  "metadata": null
}

Unlike some languages' object/dict literals, JSON keys must be strings — {1: "a"} is invalid; it must be {"1": "a"}, even when the key looks numeric.

Key order: not guaranteed by the spec

The JSON specification does not require implementations to preserve the order keys were written in — in practice, most modern parsers (including JavaScript's) do preserve insertion order as an implementation detail, but relying on this across every possible parser and language is not spec-guaranteed behavior. If order matters for your data, use an array of objects instead of relying on object key order.

What happens with duplicate keys

{"a": 1, "a": 2}

This is technically parseable JSON — the spec doesn't forbid duplicate keys — but it doesn't define what should happen when one occurs. Most parsers silently keep only the last occurrence ({"a": 2} above), discarding the earlier value with no warning. This is a genuinely dangerous edge case: a document with an accidentally duplicated key loses data silently, and different parsers aren't guaranteed to agree on which value survives.

Nested objects

Objects can contain other objects (and arrays) to arbitrary depth:

{
  "user": {
    "id": 1,
    "address": { "city": "Delhi", "zip": "110001" }
  }
}

There's no built-in depth limit in the spec, though individual parsers may impose practical recursion limits for very deeply nested documents.

Common mistakes

• Relying on key order for meaning. Use an array when order actually matters to your data model.
• Not checking for accidental duplicate keys in hand-edited or programmatically merged JSON — the silent "last value wins" behavior can hide real bugs.
• Using non-string keys. Numbers, booleans, or other types as object keys are invalid JSON; they must be quoted strings.

FAQ

Does JSON guarantee the order of object keys?
No — most parsers preserve insertion order in practice, but the spec doesn't require it; don't rely on order for data that needs to be ordered, use an array instead.

What happens if a JSON object has the same key twice?
It's valid syntax, but the spec doesn't define the resulting behavior — most parsers keep only the last occurrence and silently discard the earlier one.

Can JSON object keys be numbers?
No — keys must always be double-quoted strings, even if the key looks like a number.

Inspect and validate JSON objects, including catching duplicate keys, with the JSON Toolkit — runs entirely in your browser.