Getting Started with JSON — A Practical Guide

The name is misleading. JSON stands for JavaScript Object Notation, but it has nothing to do with JavaScript at runtime. It's a plain text format — something any language can read and write. The reason it became the default for web data exchange is that it's both machine-readable and human-readable at the same time, which isn't a given. XML is readable but verbose. Binary formats are compact but you can't look at them in a terminal and understand what's there.

A JSON document is just a string. The structure inside that string is what makes it useful.

Everything in JSON is built from two containers. An object is a collection of key/value pairs, where each key is a string and the value can be anything. An array is an ordered list of values. Nest them in any combination and you can represent almost any data structure.

{
  "name": "Alice",
  "age": 30,
  "skills": ["JavaScript", "Python"],
  "address": {
    "city": "London",
    "country": "UK"
  }
}

The keys in an object must be quoted strings — no shorthand. Values can be strings, numbers, booleans, null, objects, or arrays. That's the complete list.

JSON is strict in a few specific ways that trip people up. Keys must be double-quoted — single quotes are not valid JSON, even though they're legal in JavaScript object literals. Trailing commas are not allowed. Comments are not allowed. If you copy a JavaScript config object and try to parse it as JSON, it will often fail for one of these reasons.

The null type has a specific meaning: the key exists but has no value. It's different from a key being absent entirely, which matters when you're updating records and need to distinguish "set this to nothing" from "don't touch this field".

REST APIs return JSON. Webhook payloads arrive as JSON. Configuration files like package.json and tsconfig.json use it. Log aggregation tools serialize events as JSON so they're queryable. Once you start noticing it, JSON is everywhere — the format has won so completely that most developers rarely think about the alternatives.

The one place JSON falls short is comments. You can't annotate a JSON config file with explanations, which is why some tools use JSONC (JSON with Comments) or YAML for configuration, even though they're not standard JSON.

Malformed JSON is one of the most common debugging headaches. A missing quote, an extra comma, or a truncated payload from a network error will cause a parse failure. The error message from a JSON parser is usually specific — it'll tell you the line and position where the structure broke — but only if you can see the formatted document clearly.

Running a raw JSON payload through a formatter before trying to debug it is almost always worth the thirty seconds. Minified JSON looks like noise; formatted JSON makes structural problems visible immediately. The JSON Formatter on Toolaxo validates and pretty-prints in one step — if there's a syntax error, it tells you exactly where.