JSON in Practice: Format, Validate and Convert Without the Headache

JSON syntax in five minutes

JSON stands for JavaScript Object Notation. Despite the name, it left the JavaScript world behind long ago: today it's the format almost every API speaks, the way apps store settings, and how one system hands data to another. Its trick is being readable by humans and trivial for machines to parse at the same time.

The whole structure rests on two building blocks. The object, in curly braces { }, is a collection of "key": value pairs. The array, in square brackets [ ], is an ordered list of values. That's all you nest, as deep as you like.

{
  "name": "Ana",
  "age": 29,
  "active": true,
  "balance": 1540.50,
  "tags": ["pro", "verified"],
  "address": {
    "city": "Austin",
    "state": "TX"
  },
  "phone": null
}

There are only six possible values: string (always in double quotes), number (integer or decimal, no quotes), boolean (true or false), null, object, and array. Notice what's missing: there's no date type (a date is just a string like "2026-06-30"), there are no comments, and keys are always strings in double quotes. Single quotes don't count. Those three rules explain most of the errors you're about to meet.

The most common syntax errors (trailing commas, quotes)

Nearly every JSON error falls into half a dozen buckets. They're worth memorizing, because the parser's message is often cryptic — a generic Unexpected token pointing at the wrong line.

• Trailing comma: a comma after the last item. ["a", "b",] is invalid. Modern JavaScript tolerates it; JSON does not.
• Single quotes: {'name': 'Ana'} looks fine, but JSON requires double quotes on keys and strings.
• Unquoted key: {name: "Ana"} is a JavaScript object, not JSON. The key must become "name".
• Comments: // this breaks it. JSON has no comments, full stop.
• Missing comma between two pairs, or one comma too many between them.
• Unescaped quotes: a double quote inside a string must become \", and a backslash becomes \\.

There are subtler traps too. NaN and Infinity are not valid JSON numbers. Leading zeros (012) are forbidden. And an invisible character at the start of a file, the notorious BOM, trips parsers that don't strip it. Instead of hunting for the stray comma by eye, paste the text into the JSON Validator: it points to the exact line and column and tells you what the parser expected to find there.

Pretty-print vs minify

The same JSON can be written two opposite ways, and each fits a different moment. Pretty-printing (or formatting) adds line breaks and indentation so a human can read it. Minifying strips every spare character so the machine can ship it faster.

The same object, minified, is a single line:

{"name":"Ana","age":29,"tags":["pro","verified"]}

And formatted with 2-space indentation, for your eyes:

{
  "name": "Ana",
  "age": 29,
  "tags": ["pro", "verified"]
}

In JavaScript this is literally the third argument of JSON.stringify: JSON.stringify(obj, null, 2) indents with 2 spaces; drop that argument and everything comes out jammed together. The rule of thumb: minify in production (API responses, files traveling over the wire) and format to debug. On a large payload the savings are real — removing whitespace can shrink the file by 10% to 20% even before gzip. When you receive a JSON squeezed onto one line and need to make sense of it, the JSON Formatter reflows it with clean indentation and highlights the nested structure.

Converting to CSV, YAML and XML

JSON rarely lives alone. Sooner or later someone wants the data in a spreadsheet, in a config file, or in a legacy system that only speaks XML. The common conversions each have their own gotchas.

JSON ↔ CSV

CSV is a flat table: rows and columns, no nesting. So a clean conversion only works when your JSON is an array of objects sharing the same keys. Take this:

[
  {"name": "Ana",   "age": 29, "city": "Austin"},
  {"name": "Bruno", "age": 34, "city": "Denver"}
]

which becomes, in CSV:

name,age,city
Ana,29,Austin
Bruno,34,Denver

The keys become the header; each object becomes a row. Trouble starts when a field is itself an object or an array — there's no obvious column for it, so the tool has to "flatten" it (e.g. address.city) or serialize the whole field. Commas and line breaks inside a value force quoting in CSV. The JSON ↔ CSV Converter handles both directions and takes care of that escaping for you.

JSON ↔ YAML

YAML is the favorite for config files (Docker Compose, GitHub Actions, Kubernetes) precisely because it reads cleaner: it swaps braces and quotes for indentation. The same object looks like this:

name: Ana
age: 29
active: true
tags:
  - pro
  - verified
address:
  city: Austin
  state: TX

YAML is a superset of JSON — every valid JSON is also valid YAML. The trip out uses JSON to YAML; the trip back, once you've edited the config and need to hand it to an API that only accepts JSON, uses YAML to JSON. Mind the indentation in YAML: it uses spaces, never tabs, and one extra space can change the meaning of the whole structure.

JSON → XML

XML is more verbose because every value lives between an opening and a closing tag. The pair "name": "Ana" becomes <name>Ana</name>. Since XML has no native concept of an array, the conversion usually repeats the same tag to stand in for a list — a design choice the tool makes for you.

JSON Schema: validating the structure, not just the syntax

There's a big difference between JSON being well-formed and being correct. The text below is syntactically perfect — any parser accepts it:

{ "age": "twenty-nine", "active": "maybe" }

But if your system expects age to be a number and name to exist, this document is wrong even though it passes the syntax validator. That's where JSON Schema comes in: a JSON that describes the shape another JSON must follow. A simple schema:

{
  "type": "object",
  "required": ["name", "age"],
  "properties": {
    "name":   { "type": "string" },
    "age":    { "type": "integer", "minimum": 0 },
    "active": { "type": "boolean" }
  }
}

This schema says: it must be an object, name and age are required, and age has to be a non-negative integer. Validating against a schema is what separates a robust API from a fragile one: you reject bad data at the door, before it poisons the database. For day-to-day work, first make sure the syntax is clean in the JSON Validator; the schema comes after, as a second layer of checking.

Frequently asked questions

Can JSON have comments?

No, the spec doesn't allow them. If you need to annotate a config file, consider YAML (which accepts # for comments) or variants like JSON5 and JSONC — remembering that those aren't pure JSON and not every parser understands them. Before sending data to an API, convert it back to clean JSON.

What's the difference between formatting and minifying?

They're opposite operations on the same content. Formatting adds spaces and line breaks for a human to read; minifying removes all of that so the machine can transmit it faster. Neither changes the data itself — only its presentation. Use the JSON Formatter to switch between the two.

Why do large numbers "break" in JSON?

JSON doesn't distinguish integers from decimals — every number is a double-precision float. That means integers above 2^53 (about 9 quadrillion) lose precision. Very long IDs, for that reason, usually travel as a string in JSON rather than as a number.

Can I convert any JSON to CSV?

Only with caveats. CSV is flat; JSON is hierarchical. The conversion is direct for an array of shallow objects, but nested structures have to be flattened or serialized into a single column. If your JSON has objects inside objects, expect some loss of fidelity on the way out, and test the result in the JSON ↔ CSV Converter.

Are JSON and YAML interchangeable?

Almost. Because YAML is a superset of JSON, every valid JSON is also valid YAML, and you can round-trip without losing data using JSON to YAML and YAML to JSON. The practical difference is usage: JSON dominates APIs and data exchange; YAML dominates config files that people edit by hand.