{
"name": "Ada",
"role": "engineer"
}Example: Useful for API request bodies or configuration examples where you need named fields.
Gotcha: JSON keys and string values must use double quotes, not single quotes.
Use this reference when you need a valid JSON shape quickly. The focus is practical examples you can paste into APIs, configs, and payload tests.
{
"name": "Ada",
"role": "engineer"
}Example: Useful for API request bodies or configuration examples where you need named fields.
Gotcha: JSON keys and string values must use double quotes, not single quotes.
{
"tags": ["php", "laravel", "testing"]
}Example: A compact shape for tags, selected items, or IDs that belong together.
Gotcha: Arrays preserve order. If order matters in your app, keep that behavior explicit.
{
"is_active": true,
"archived_at": null
}Example: Useful when modeling optional values and status flags in a payload.
Gotcha: `true`, `false`, and `null` are bare JSON literals. Do not wrap them in quotes unless you want strings.
{
"message": "She said \"ship it\" today."
}Example: Use this when embedding user-visible text or snippets that contain double quotes.
Gotcha: If the string content is already escaped by your programming language, do not escape it twice before encoding JSON.
JSON is deliberately small, which is exactly why small mistakes cause outsized friction. One missing quote, a trailing comma, or an invalid assumption about comments can break an API request, a config payload, or a test fixture instantly. This reference is built for the moments when you know the structure you want but need the exact JSON syntax again.
If you searched for JSON Reference, JSON Syntax, JSON Schema reference, or $ref examples, you are usually looking for one of three things: valid core syntax, a reusable object pattern, or an explanation of how references work in schema-driven tooling. This page covers all three without mixing them together.
| Pattern | Example | Why it matters |
|---|---|---|
| Object | { "id": 7, "name": "Ada" } |
Key-value structure for named fields |
| Array | ["red", "green", "blue"] |
Ordered list of values |
| Nested object | { "user": { "id": 7 } } |
Groups related fields cleanly |
| Boolean and null | { "active": true, "deletedAt": null } |
Use JSON literals, not strings |
| Escaped quotes | { "msg": "She said \"hi\"" } |
Strings must remain valid JSON |
| No trailing comma | { "id": 1 } |
A trailing comma breaks strict parsers |
| No comments | invalid in pure JSON | Many editors allow them, parsers often do not |
| Schema reference | { "$ref": "#/$defs/User" } |
Reuse definitions in supported schema contexts |
```json
{
"service": "billing-api",
"port": 8080,
"features": ["invoices", "refunds"],
"database": {
"host": "db.internal",
"ssl": true
},
"retryCount": 3,
"maintenanceWindow": null
}
```
The important thing here is not that the structure is complex. It is that every value uses JSON-native types. Numbers are not quoted. Booleans are not written as "true". Null stays null. JSON stays reliable when the types remain honest.
In plain JSON, there is no built-in pointer or object-reference feature. JSON is just a data format. It does not define aliasing, variables, or graph references. That is why developers often ask whether references are possible in JSON at all.
The answer is: not in raw JSON syntax itself, but many systems built around JSON add their own reference conventions. The most common example is JSON Schema, where $ref lets you reuse a definition or point to another schema resource. That is a schema-layer feature, not a native language feature of plain JSON.
$ref in schema-style documents```json
{
"$defs": {
"User": {
"type": "object",
"properties": {
"id": { "type": "integer" },
"email": { "type": "string" }
},
"required": ["id", "email"]
}
},
"type": "object",
"properties": {
"owner": { "$ref": "#/$defs/User" }
}
}
```
This is the pattern most people mean when they ask how to use JSON references. $ref is meaningful in tools that implement JSON Schema or a related convention. It is not a generic way to express object identity inside every JSON document you write.
If your application needs one object to refer to another, the common practical approach is to store an identifier rather than a direct in-memory reference. For example:
```json
{
"orderId": 82,
"customerId": 14
}
```
That looks less magical than an actual pointer, but it is portable, serializable, and easy to validate. This is why JSON works so well in APIs: objects are transferred as data, while relationships are represented explicitly.
| Mistake | Why it fails |
|---|---|
| Using single quotes | JSON strings and keys require double quotes |
| Adding comments | Standard JSON does not allow // or /* */ comments |
| Leaving trailing commas | Many parsers reject them |
| Treating all values as strings | Types matter for validators and consumers |
Assuming $ref works everywhere |
It only works where the parser or schema engine supports it |
Not in plain JSON itself. References are usually introduced by a higher-level convention such as JSON Schema and $ref.
$ref work?A $ref value points to another schema location or external schema resource. The exact behavior depends on the schema implementation, but the intent is reuse rather than duplication.
Use explicit identifiers such as userId, orderId, or a URI. That keeps the payload simple and portable.
Keep the structure strict: double quotes, no trailing commas, correct value types, and no comments unless you are using a non-standard format such as JSONC intentionally.
Once the JSON shape is clear, compare it with the YAML reference for config-oriented syntax, use the regex reference to extract values safely from text, return to the Developer Reference Hub for adjacent workflows, or open the MySQL reference when JSON payloads turn into stored records.
JSON can feel unforgiving compared with looser configuration formats, but that strictness is exactly why it travels well between services and tools. When a parser accepts the document, every consumer sees the same structural truth: keys, arrays, numbers, booleans, nulls, and nesting. That predictability is why JSON remains the default format for APIs and machine-to-machine payloads even when humans complain about the quotes.
Programs must be written for people to read, and only incidentally for machines to execute.
…
…