A beginner's guide to JSON (with real-world examples)

The fastest way to learn JSON isn't a syntax diagram, it's reading real examples until the shape becomes obvious. So that's what this is: three real-ish JSON documents, read line by line, with the gotchas called out as they come up.

Example one: a weather API response

A typical response looks like this in shape: an outer object holding a city name, a temperature number, and a nested object for wind data containing speed and direction. The outer curly braces mark an object — a collection of key-value pairs. Keys are always wrapped in double quotes, never single quotes, and never left bare. Values can be strings (in quotes), numbers (no quotes), booleans (true or false, lowercase, no quotes), null, another object, or an array.

Example two: a config file

Config files usually look like objects containing simpler objects: a "theme" key holding "dark", a "maxRetries" key holding the number 3, and a "features" key holding an array of strings like ["beta", "newDashboard"]. Arrays use square brackets, and every item inside is separated by a comma — except the last one, which must not have a trailing comma. This is the single most common mistake beginners make, because many programming languages happily allow a trailing comma and JSON does not.

Example three: something broken, and how to fix it

Here's a payload that fails to parse: keys written without quotes, a trailing comma after the last array item, and a comment left in from testing (JSON has no comment syntax at all — none, in any form). Fixing it means quoting every key, deleting the trailing comma, and removing the comment entirely. Running it through a JSON validator will point at the exact line and character where parsing failed, which is far faster than scanning by eye once files get past a few dozen lines.

The types, once more, briefly

Six types exist in JSON, full stop: string, number, boolean, null, object, and array. There's no date type (dates are almost always transmitted as ISO 8601 strings like "2026-04-28T10:00:00Z"), no undefined, and no way to represent a function or a comment. This is a feature — JSON's entire appeal is being a strict, unambiguous, language-independent data format.

Where JSON shows up that beginners don't expect

Beyond APIs, JSON quietly runs your browser's localStorage, most editor and IDE settings files, package.json in nearly every JavaScript project, and the majority of infrastructure-as-code tool outputs. Once you can read it fluently, a surprising number of "how do I configure this" problems become five-minute fixes instead of guesswork.

Common pitfalls, ranked by how often I see them

Trailing commas top the list, followed by using single quotes instead of double quotes, followed by forgetting that numbers with leading zeros (like 007) aren't valid JSON numbers at all, followed by trying to leave a comment for a teammate directly inside the file.

Nesting depth: where beginners get lost

A payload three or four levels deep an order object containing a customer object containing an addresses array containing address objects is where most beginners lose track of which closing bracket matches which opening one. The trick that actually helps: read only the indentation, ignore the content, and confirm every opening brace or bracket has a matching one at the same indent level directly below it. A code editor with bracket-matching highlighting (click just after a brace and watch its pair light up) turns this from guesswork into a two-second check.

A quick worked fix, start to finish

Given a broken snippet like {name: "Alex", age: 29,} the fix, in order: wrap name in double quotes, wrap Alex's quotes are already fine, leave age as a bare number since numbers never take quotes, and delete the trailing comma after 29. Three small edits, and the file goes from unparsable to valid. Practicing this exact sequence on a few broken examples builds the pattern-matching skill faster than reading the JSON specification ever will.

Escaping characters inside strings

Certain characters inside a JSON string value must be escaped with a backslash: a literal double quote becomes \", a backslash itself becomes \\\\, and a newline becomes \\n. Forgetting to escape a quote inside a string — for example storing a value like "the \"best\" tool" without escaping the inner quotes — is a common source of parse errors that looks correct to the eye but fails validation immediately, because the parser reads the second quote as the end of the string and gets confused by everything after it.

Numbers: the quirks that trip people up

JSON numbers look simple but hide two real gotchas. First, there's no distinction between integers and floats in the format itself — 3 and 3.0 are both just numbers, and it's up to whatever reads the JSON to decide how to store them. Second, very large integers (bigger than about nine quadrillion) can silently lose precision when parsed in JavaScript, because JavaScript represents all numbers as 64-bit floats internally; APIs dealing with large IDs often send them as strings specifically to dodge this problem, which is why you'll sometimes see an ID field quoted even though it's entirely digits.

One more habit worth building: whenever a JSON payload looks suspiciously nested for no reason, check whether it's actually a string containing JSON inside a JSON value, a pattern common in logging systems, since that inner string needs a second parse pass before it becomes usable data.

Questions worth asking

Can JSON have comments? No, never — if you need to document a JSON config file, add a companion README or use a format that supports comments, like JSON5 or YAML, instead.

Why does my JSON fail to parse even though it looks fine? The most common invisible causes are a trailing comma, a stray single quote, or an unescaped double quote inside a string value — a validator will point to the exact character.

Is JSON the same as a JavaScript object? They look similar but JSON is a strict text format with rules JavaScript objects don't enforce, like requiring double-quoted keys; a JavaScript object can hold functions and JSON cannot.

What's the difference between JSON and XML? JSON is generally more compact and easier to parse for machines, while XML supports attributes, namespaces, and comments that JSON deliberately leaves out.