JSON — JavaScript Object Notation — is the language that APIs, configuration files, and countless applications use to exchange data. It was designed to be readable by both people and machines, but that readability only holds when the JSON is properly formatted. A wall of minified, single-line JSON is nearly impossible to debug by eye, and a single misplaced comma can break an entire file.
This guide covers JSON's handful of rules, how to format and validate it so you can actually read it, the most common errors and how to spot them, and how to convert between JSON and the CSV format that spreadsheet users prefer.
The entire structure of JSON comes down to a few consistent rules:
That is essentially the whole specification. Its simplicity is why JSON became the default data format of the modern web.
Data arrives from APIs "minified" — stripped of whitespace to save bandwidth — which makes it compact but unreadable. Formatting, also called pretty-printing, adds indentation and line breaks that reveal the structure.
Paste raw JSON into the JSON Formatter and it indents everything into a clean, nested layout. Suddenly the shape of the data is obvious: you can see which values belong to which keys, how arrays are nested, and — crucially — where something is missing or misplaced.
Nearly all "invalid JSON" errors come from a short list of mistakes:
A validator that pretty-prints as it checks points you straight to the offending line, which turns a frustrating hunt into a quick fix.
This habit is especially valuable for configuration files, where a broken JSON file can take down a service, and the cause — a stray comma added during a quick edit — is easy to miss by eye but obvious to a validator.
JSON and CSV solve different problems. JSON handles nested, hierarchical data — an object containing arrays containing more objects — which makes it ideal for API responses and configuration. CSV is flat: rows and columns, like a spreadsheet, perfect for tabular data headed into Excel or a database import.
Use JSON when your data has structure and relationships; use CSV when it is a simple table. Neither is better overall — they fit different shapes of data, and knowing which to reach for saves a lot of conversion headaches.
In practice you often need to move between the two, because developers work in JSON while analysts and clients want spreadsheets. Converting by hand is tedious and error-prone.
The JSON to CSV converter flattens JSON into a spreadsheet-ready table, and the CSV to JSON converter turns a CSV export back into structured JSON for use in code. Keeping both handy means you can give everyone the data in the format they prefer without manual reformatting — the developer gets JSON, the client gets a spreadsheet, and neither has to translate.
JSON supports a small, fixed set of value types, and knowing them precisely prevents a lot of errors. Every value in a JSON document is one of these:
The distinction between a number and a string that looks like a number causes surprisingly many bugs. The value 42 and the value "42" are different in JSON, and a program expecting one may fail on the other. Similarly, true and "true" are not the same. When JSON behaves unexpectedly in code, a mismatch between a quoted string and an unquoted number or boolean is one of the first things to check — and formatting the JSON to inspect it closely makes these mismatches easy to spot.
Understanding JSON's rules is most useful when you see where the format actually turns up, because the same skills apply across every context. Two dominate: web APIs and configuration files.
When an application talks to a web service — fetching weather data, submitting a form, loading your social feed — it almost always exchanges JSON. The application sends a JSON request and receives a JSON response, and being able to read that response is essential for understanding what a service returned or why a call failed. Formatting a raw API response makes its structure clear, revealing exactly which fields are present and how they are nested, which is the first step in debugging almost any integration problem.
Configuration files are the other major home for JSON. Countless tools and projects store their settings as JSON, and here the stakes of getting the syntax right are high: a single trailing comma or missing brace can stop a program from starting, often with an unhelpful error message. This is why validating a config file after editing is such a valuable habit — it catches the small mistakes that are otherwise painful to track down. Whether you are consuming an API or editing a settings file, the routine is the same: format it to see the structure, validate it to catch errors, and fix the specific line the validator flags. Those two steps handle the overwhelming majority of everyday JSON problems.