English ▾
Free, Fast & Secure Online Tools
JSON stands for JavaScript Object Notation, which is a misleading name — it has very little to do with JavaScript now and is used by everything. It is a plain-text way of writing structured data, and it is what you get when you ask a service to export your account, when an app stores its settings, and when one program sends data to another.
A small example contains nearly everything the format can do:
{
"name": "Widget",
"price": 4.50,
"inStock": true,
"tags": ["small", "blue"],
"discount": null
}
Curly braces hold an object — a set of named values. Square brackets hold an array — an ordered list. And that is the entire type system: objects, arrays, strings, numbers, true/false, and null. Six things.
Objects and arrays can contain each other to any depth, which is how JSON describes complicated structures out of such a small vocabulary.
JSON is strict in a way that surprises anyone who has written code in a real programming language, because it looks like several of them and forbids things they allow.
'name' is invalid. Every string and every key needs double quotes.name: "Widget" is invalid; "name": "Widget" is correct.//, not /* */. This is the most complained-about omission in the format’s history, and it was deliberate: comments invite people to put meaning in places parsers ignore.The comment ban has a universal workaround: add an ordinary key such as "_comment" with your note as its value. It is not a comment — programs will read it as data — but it is where everyone puts explanations in a configuration file.
This is worth understanding because it makes error messages much less frustrating.
JSON has no way to recover from a syntax error. There are no record boundaries the way a CSV has lines, so a parser that encounters something unexpected cannot skip the bad part and carry on — the whole file fails.
Worse, the reported line number is where the parser noticed, not where you made the mistake. Leave out a closing brace near the top and the error appears at the very end of the file, because that is the first point at which the structure became impossible. Leave out a comma and the message often points at the line after the one you need to fix.
So when a JSON error names a line, look at the structure above it rather than the line itself. A validator or an editor that highlights matching brackets finds these far faster than reading does.
Both are plain text and both describe structure. JSON won for data exchange on two points.
The first is weight. A value in XML is wrapped in an opening and a closing tag; in JSON it is a name, a colon and the value. Across a large file that is a substantial difference in both size and readability.
The second matters more: JSON’s six types map directly onto the data structures that every programming language already has. An object becomes a dictionary, an array becomes a list, a number becomes a number. XML needs interpretation — everything is text until something decides what it means.
What JSON gives up in exchange is anything to do with documents: no comments, no attributes, no namespaces, and no way to represent text with markup inside it. That is why data travels as JSON and documents stay in XML.
This is the common practical task, and whether it works depends entirely on the shape of your data.
A flat array of objects converts cleanly. A list of records that all have the same fields is a table: one row per object, one column per key. Any conversion tool handles it.
Nested data does not. If each record contains an array of other objects — an order with several items, a user with multiple addresses — there is no honest way to put that in a grid. The conversion either flattens it into columns named items.0.name, items.1.name and so on, or it drops the nesting entirely.
This is not a limitation of the converter. A spreadsheet is a rectangle and JSON is a tree, and trees do not fit in rectangles. Where the data genuinely is nested, the useful move is usually to extract the one part you actually need as a flat list, rather than trying to convert the whole structure.
A large export is often not one JSON document but a file with one complete JSON object per line, known as JSONL or NDJSON.
The reason is practical: a single giant JSON array has to be read entirely into memory before anything can be done with it, and nothing can be appended without rewriting the file. One object per line can be processed a line at a time and appended to forever.
If a file has .jsonl or .ndjson on it, or opens as many lines each starting with {, that is what it is — and feeding it to a plain JSON parser will fail, because the file as a whole is not valid JSON.
Everything true of Markdown on this point is true here. JSON opens in any text editor, survives any software disappearing, can be searched with ordinary tools, and compares line by line between versions.
The one practical step is to pretty-print it before reading. Exported JSON often arrives as a single enormous line. Any formatter or capable editor will re-indent it into something a person can follow, without changing the data.
"_comment" key when you need to leave a note