A single extra comma can break an entire app. Put a comma after the last item in a list — ["cat", "dog",] — and a file that looks perfectly reasonable to you becomes garbage to every program that reads it. There's no error you'd catch by eye. Just a config that silently fails to load, or an API that returns nothing.
That stray comma is a JSON error, and JSON is probably the most common data format you've never been formally introduced to. If you've ever opened a .json file, copied an API response, or edited a settings file for an app, you've already handled it. Here's what it actually is, and how to stop it from biting you.
What JSON actually is
JSON stands for JavaScript Object Notation, but you don't need to know JavaScript to read it. It's just text — a way of writing down structured information so both humans and machines agree on what it means.
Think of a business card. It has a name, a phone number, a company, maybe a list of office locations. JSON is that card written in a strict, predictable format:
{
"name": "Ada Lovelace",
"age": 36,
"active": true,
"pets": ["cat", "dog"],
"address": null
}
That's the whole idea. Labels on the left, values on the right, wrapped in punctuation that tells a computer where each piece begins and ends. Any programming language — Python, JavaScript, Ruby, whatever — can read that and know for certain the person's age is 36 and they have two pets.
The building blocks
There are only a handful of pieces, and once you see them you'll spot them everywhere.
Key/value pairs are the core. "name": "Ada Lovelace" is a key ("name") paired with a value ("Ada Lovelace"), separated by a colon. The key is always text in double quotes.
Objects are groups of pairs wrapped in curly braces { }. The example above is one object. Objects can hold other objects — an "address" value could itself be {"city": "London", "zip": "SW1"}.
Arrays are ordered lists wrapped in square brackets [ ]. ["cat", "dog"] is an array of two items. Order matters, and items are separated by commas.
Values are the things on the right side of the colon, and there are six types. Four are simple: strings (text in double quotes), numbers (36, no quotes), booleans (true or false), and null, which means "nothing here." The other two are objects and arrays themselves — a value can be a whole object or array, and that's how JSON nests as deep as you need.
The distinction that trips people up: "36" and 36 are not the same thing. The first is text that happens to contain digits; the second is a real number you can do math on. Quotes change the meaning.
Minified vs pretty-printed
The same JSON can be written two ways. Pretty-printed is what you saw above — line breaks, indentation, easy to read. Minified is identical data with every unnecessary space stripped out:
{"name":"Ada Lovelace","age":36,"active":true,"pets":["cat","dog"],"address":null}
Computers don't care which they get; the data is the same. But when an API sends you a 2 MB response, it sends it minified to save bandwidth — and it lands as one unbroken wall of text. That's the moment you paste it into a formatter to add the line breaks back and actually see the structure. Dropping a minified blob into the JSON Formatter turns that wall into something readable in seconds, and it runs entirely in your browser — nothing is uploaded, which matters when the JSON contains API keys or customer records.
Why APIs and config files speak JSON
Two reasons JSON won.
First, it's language-neutral. When an app on your phone talks to a server, the two may be written in completely different languages. JSON is the common tongue both sides parse without argument. Almost every web API — weather data, payment systems, maps — sends and receives JSON.
Second, it's human-editable. App settings, editor preferences, the package.json file in a code project — these are JSON because a person occasionally needs to open the file and change a value by hand. Structured enough for a machine, plain enough for a human. That combination is rare.
The three errors that break almost everything
JSON is strict, and strictness is unforgiving. Three mistakes cause the large majority of "invalid JSON" errors:
Trailing commas.
["cat", "dog",]— the comma after"dog"with nothing following it is illegal. This one is sneaky because JavaScript code allows trailing commas, so people assume JSON does too. It doesn't.Single quotes.
{'name': 'Ada'}looks fine and is valid in Python and JavaScript. In JSON it's an error — strings and keys must use double quotes.{"name": "Ada"}is the only correct form.Unquoted keys.
{name: "Ada"}— the key has to be a quoted string.{name:...}works in a JavaScript object but is not valid JSON.
The trouble with all three is that the error message is usually useless: "Unexpected token at position 47." Counting to character 47 by hand in a wall of text is miserable.
That's exactly what a validator saves you from. Paste your JSON into a formatter and it does two jobs at once: it re-indents everything so the structure is visible, and it points to the precise line and character where parsing failed. A mismatched bracket or a stray comma that was invisible in one long line jumps out the moment the text is properly spaced. Ninety percent of debugging JSON is just seeing it clearly.
When JSON isn't the right approach
JSON is not a spreadsheet. If your data is a simple flat table — rows and columns, no nesting — CSV is smaller, opens in Excel, and is easier for non-technical people to edit. Forcing tabular data into JSON only adds noise.
It also has no comments. You cannot leave a // note to self inside a strict JSON file, which makes complex config files hard to document. Some tools use relaxed variants like JSON5 or YAML specifically to allow comments — but those are not standard JSON, and pasting them into a strict validator will fail.
And JSON has no built-in idea of a date, a currency, or a "big number" beyond what a standard number can hold. A date is just a string like "2026-09-12", and it's on the receiving program to interpret it. If you need those guarantees, JSON alone won't give them to you.
For most everyday jobs — reading an API response, fixing a config file, checking why an import failed — none of that matters. What matters is being able to read the thing and spot the broken comma.
Next time an app throws an "invalid JSON" error, don't hunt for the mistake by eye. Paste the text into a formatter, let it point at the exact character, fix that one spot, and move on. The comma was never worth ten minutes of squinting.