Learn what JSON is and why structured data matters.
Why does
{ name: "Jit-CSS" }
fail to parse as JSON, while
{ "name": "Jit-CSS" }
works fine — what's actually different about that one pair of quotes?
JSON requires every single key to be a double-quoted string, with no exceptions — even though plain JavaScript object literals, which JSON's syntax was modeled on, happily allow unquoted keys as a shorthand. JSON is a deliberately strict subset of that more relaxed syntax, specifically so that any parser, written in any language, reads the exact same document the exact same way without needing to guess. A JavaScript engine's forgiving object-literal parser and a strict JSON parser look almost identical but are not the same thing, and only one of them accepts
{ name: "Jit-CSS" }.
JSON stands for JavaScript Object Notation — a plain text format for structured data, designed to move information between systems regardless of what programming language is running on either end. A server written in PHP, a browser running JavaScript, and a script written in Python can all read and write the exact same JSON document without translation.
Every value anywhere in a JSON document, no matter how deeply nested, must be one of exactly six types: a string, a number, a boolean,
null, an object, or an array. There is no seventh option, and no way to store something like a function or a date directly — which is exactly why dates in JSON always end up stored as plain strings that something else has to parse back into a real date afterward.
Strings are always wrapped in double quotes, never single quotes. Numbers are written with no surrounding quotes and no leading zero. The literals
true,
false, and
null
are written in lowercase, with no quotes at all — quoting any of them turns it into a string instead, a completely different value.
An object groups key-value pairs inside curly braces; an array holds an ordered list of values inside square brackets. These are the only two structural containers in JSON, and every other value — strings, numbers, booleans, null, even more objects and arrays — lives inside one of these two shapes.
This lesson's example is one complete, small JSON document describing a single course — built specifically to use every one of the six value types at once. Every later lecture in this course points back to a piece of this exact same document.
"id": 101 — A number, written with no quotes at all. Quoting it as
"101"
would turn it into a string instead, a different value that behaves differently the moment something tries to do math with it.
"name": "Jit-CSS"
and
"free": true — A string and a boolean, sitting right next to each other. The string needs double quotes around its value; the boolean must not have any quotes around it at all — mixing the two rules up is one of the most common small JSON mistakes.
"instructor": null — This says, deliberately, "this field exists, and currently has no value" — a different statement from leaving the
instructor
key out of the object entirely, which could mean either "no instructor" or "this field was never filled in at all."
"tags": ["web", "beginner"] — An array: an ordered list of two strings, inside square brackets. This is the smallest possible look at the structure a later lesson covers in much more depth.
"stats": { "students": 4200, "rating": 4.8 } — An object nested inside the outer object — a second, smaller set of key-value pairs living as the value of one single key. This is the seed of nesting, the subject of a later lecture in this series.
Quoted keys are what make JSON portable across languages
A PHP server, a Python script, and a JavaScript browser all reject an unquoted key in the exact same way, with the exact same error — that shared, strict rule is exactly what lets a JSON file written by one of them be read correctly by the other two, without three different sets of parsing rules to remember.
null and a missing key are not the same situation
A course record with
"instructor": null
actively rules out "we forgot this field" — the field is there, and is intentionally empty. Leaving the key out entirely leaves both possibilities open, which can matter a great deal to code trying to decide whether something is missing or simply unset.
JSON's number format is stricter than it looks
4.8
is a valid number, but
4.
and
04.8
are not — no trailing decimal point with nothing after it, and no leading zero. Both of those look completely ordinary to a person reading them and are rejected outright by a strict parser.
A quoted boolean silently becomes a different value entirely
"free": "true"
stores the three-character string "true," not the boolean
true. Code that later checks this value with
=== true
will get
false
back for that comparison, even though the field visually says "true" right there in the data.
There is no escape hatch beyond the six value types
JSON has no native way to store a date, a function, or any custom type directly — only the six values this lesson covers. Anything else, like a date, has to be represented as one of those six (almost always a string) and converted back into something more specific by whatever code reads it afterward.
Unquoted keys and single-quoted strings — avoid
{
id: 101,
name: 'Jit-CSS',
free: true
}
Double-quoted keys and strings, exactly as JSON requires — use this
{
"id": 101,
"name": "Jit-CSS",
"free": true
}
Paste your JSON into ChatGPT and ask: "Does every key and string value here use double quotes, and is anything that should be a boolean or number accidentally quoted as a string instead?" It's good at spotting both, though running the same document through an actual validator like JSONLint is worth doing too, since a strict parser will catch anything a quick read misses.
Write the course object from this lesson by hand, using all six value types at least once somewhere in the document.
Remove the quotes from one key and paste the result into a JSON validator. Read the exact error message it produces.
Change
"free": true
to
"free": "true", parse both versions in a JavaScript console with
JSON.parse(), and compare
result.free === true
for each one.
Add a field set to
null
and a second, similar field that's simply left out of the object entirely. Explain the difference between the two in your own words.
Try writing a number with a leading zero, like
"price": 04, and confirm a validator rejects it.
Writing JSON keys without quotes out of habit from plain JavaScript object literals, where that shortcut is allowed but JSON's stricter grammar does not permit it.
Using single quotes for strings instead of double quotes, another habit that's valid in JavaScript but invalid in JSON specifically.
Quoting
true,
false, or
null
as if they were strings, silently turning a boolean or null value into a completely different kind of value.
Leaving a field out of an object when the intent was actually to say "this exists but has no value yet," when
null
would have stated that intent clearly instead.
Writing a number with a leading zero or a trailing decimal point with nothing after it, both of which look ordinary to a person reading them but are rejected by a strict JSON parser.
Read or write a JSON document using each of the six value types correctly, and explain exactly which syntax rules separate strict JSON from a plain JavaScript object literal that merely looks like it.
