JSONValidator.in

What Is JSON? The Complete Guide

Everything from the absolute basics to advanced, production-level JSON concepts — syntax, data types, validation, security, and how JSON compares to XML, YAML, and CSV.

1. What is JSON?

JSON stands for JavaScript Object Notation. It's a lightweight, text-based format for representing structured data — objects, arrays, strings, numbers, booleans, and null values — in a way that's easy for both humans to read and machines to parse. Despite the name, JSON is not tied to JavaScript: it's a language-independent data format with parsers and generators available in essentially every programming language in use today, from Python and Java to Rust and Go.

At its core, JSON represents data as key-value pairs and ordered lists, nested as deeply as needed. If you've ever seen a response from a web API, opened a modern configuration file, or inspected a NoSQL database document, you've almost certainly seen JSON. It has become the de facto standard for exchanging data between a server and a web application, between microservices, and increasingly for configuration and data storage in general.

JSON's popularity comes down to a simple trade-off: it captures nearly everything most applications need to represent structured data — nesting, lists, key-value maps, and a small set of primitive types — without the verbosity of formats like XML or the whitespace-sensitivity of formats like YAML.

2. A brief history of JSON

JSON was derived from JavaScript's object literal syntax and popularized in the early 2000s by Douglas Crockford, who specified the format and registered the json.org website in 2001. Crockford didn't invent object literals — that syntax was already part of JavaScript — but he recognized that a strict subset of that syntax made an excellent, minimal data-interchange format, and gave it a name and a formal specification.

JSON was later standardized as RFC 8259 (which obsoleted the earlier RFC 7159 and RFC 4627) by the Internet Engineering Task Force, and separately as ECMA-404 by Ecma International. Every JSON validator on the internet, including the one on this site, ultimately checks a document against the grammar defined in these specifications.

3. JSON syntax rules

JSON's entire grammar fits on a single page. The rules that matter most in practice are:

  • Objects are wrapped in curly braces { } and contain comma-separated "key": value pairs.
  • Keys must always be double-quoted strings — single quotes and unquoted keys are not valid JSON, even though they're valid JavaScript.
  • Arrays are wrapped in square brackets [ ] and contain comma-separated values of any type, including mixed types.
  • Strings must use double quotes, never single quotes, and support standard escape sequences like \n, \t, and \uXXXX for Unicode characters.
  • No trailing commas are allowed after the last item in an object or array.
  • No comments — JSON has no syntax for // or /* */ comments, which trips up many developers coming from JavaScript or C-like languages.
  • Numbers don't support leading zeros, hexadecimal notation, NaN, or Infinity — only standard decimal notation, with optional exponents.

Every one of these rules is exactly what our JSON Validator checks for, reporting the exact line and column of the first rule that's broken.

4. JSON data types

JSON supports exactly six data types — no more, no less:

  • String — text wrapped in double quotes, e.g. "hello".
  • Number — integers or decimals, e.g. 42 or 3.14. JSON does not distinguish integers from floats; that distinction is left to the parser in whichever language reads it.
  • Boolean — true or false, always lowercase.
  • Null — the literal null, representing an intentionally empty value.
  • Object — an unordered set of key-value pairs, where values can be any JSON type, including nested objects.
  • Array — an ordered list of values of any JSON type, including nested arrays and objects.

Notably absent: dates, functions, undefined, and binary data. Dates are almost always represented as ISO 8601 strings (e.g. "2026-07-04T10:00:00Z") by convention, not as a native type — it's up to your application to parse them.

5. A complete example, annotated

{
  "id": 4471,                     // number
  "name": "Asha Verma",           // string
  "isActive": true,               // boolean
  "signupDate": "2024-03-11",     // string (dates are conventionally ISO 8601)
  "roles": ["admin", "editor"],   // array of strings
  "manager": null,                // null
  "address": {                    // nested object
    "city": "Pune",
    "pincode": "411001"
  }
}

(Note: real JSON cannot contain the // comments shown above — they're included here purely to annotate the example for this guide.)

6. JSON vs XML vs YAML vs CSV

JSON isn't the only data-interchange format, and each of its main alternatives makes different trade-offs:

  • JSON vs XML — XML predates JSON and supports richer features like namespaces, attributes, and schema validation via XSD, but is far more verbose. JSON has largely replaced XML for web APIs because it's smaller, faster to parse, and maps directly onto native data structures in most programming languages.
  • JSON vs YAML — YAML is a superset of JSON's data model with a more human-friendly, indentation-based syntax and support for comments — popular for configuration files (like Docker Compose or Kubernetes manifests). The trade-off is that YAML's whitespace sensitivity and implicit typing (e.g. the string "no" can be silently parsed as boolean false in some parsers) make it more error-prone to hand-edit than JSON.
  • JSON vs CSV — CSV is a flat, tabular format ideal for spreadsheet-style data with a fixed set of columns. It has no native support for nesting, so representing hierarchical data in CSV requires flattening it — which is exactly what our JSON to CSV converter does automatically.

In short: reach for JSON for APIs and data interchange, YAML for human-edited configuration, XML when you need namespaces or you're integrating with legacy enterprise systems, and CSV when your data is genuinely tabular and destined for a spreadsheet.

7. Where JSON is used

  • Web APIs — the overwhelming majority of REST and GraphQL APIs send and receive JSON.
  • Configuration files — package.json, tsconfig.json, and countless other tool configs use JSON.
  • NoSQL databases — document databases like MongoDB store records as JSON-like BSON documents natively.
  • Browser storage — localStorage and sessionStorage commonly store serialized JSON.
  • Mobile app data exchange — native iOS and Android apps parse JSON from backend services as their primary data format.
  • Log files — structured logging tools increasingly emit one JSON object per line (see NDJSON in Section 15) for easy machine parsing.
  • Infrastructure as code — tools like AWS CloudFormation support JSON templates alongside YAML.

8. How to validate JSON

Validating JSON means checking that a document follows the syntax rules in Section 3 — nothing more. A validator doesn't check whether the data makes sense for your application (that's what JSON Schema is for) — only whether it's syntactically well-formed and can be parsed without error.

The fastest way to validate JSON is to paste it into our free online JSON Validator, which runs entirely in your browser and reports the exact line and column of any syntax error along with a plain-language explanation — no signup, and your data is never uploaded anywhere.

9. How to format and minify JSON

JSON returned by an API is often minified — all on one line, with no spacing — to save bandwidth. That's great for machines but nearly unreadable for humans. Formatting (also called pretty-printing) adds consistent indentation and line breaks so nested structures are easy to scan, without changing the underlying data. The reverse operation, minifying, strips all unnecessary whitespace to shrink the payload before sending it over the network.

Our JSON Formatter does both — choose 2-space, 4-space, or tab indentation, or switch to Minify for a single compact line — and can optionally sort object keys alphabetically to make diffs easier to review.

10. Common JSON errors and how to fix them

The vast majority of "invalid JSON" errors come down to a small handful of mistakes:

  • Trailing commas — a comma left after the last item in an object or array, e.g. {"a": 1,}.
  • Single-quoted strings — JSON requires double quotes; {'a': 1} is invalid.
  • Unquoted keys — {a: 1} is valid JavaScript but invalid JSON; it must be {"a": 1}.
  • Missing commas between elements or key-value pairs.
  • Comments — JSON has no comment syntax, so any // or /* */ will cause a parse error.
  • Unbalanced brackets — a missing closing } or ], often from copy-pasting a partial response.

Rather than fixing these by hand, our JSON Repair tool detects and automatically corrects every one of these, and shows you a step-by-step log explaining exactly what it changed.

11. Working with JSON in different languages

Nearly every language has JSON support built into its standard library:

// JavaScript
const obj = JSON.parse('{"id": 1}');
const str = JSON.stringify(obj, null, 2);

# Python
import json
obj = json.loads('{"id": 1}')
text = json.dumps(obj, indent=2)

// Java (with Jackson)
ObjectMapper mapper = new ObjectMapper();
Map<String, Object> obj = mapper.readValue(json, Map.class);

// Go
var obj map[string]interface{}
json.Unmarshal([]byte(jsonStr), &obj)

// PHP
$obj = json_decode($jsonStr, true);
$str = json_encode($obj);

The pattern is the same everywhere: a parse/decode function turns a JSON string into a native data structure, and a stringify/encode function does the reverse.

12. JSON Schema: validating structure, not just syntax

Syntax validation only confirms a document is well-formed JSON — it says nothing about whether the data has the shape your application expects. JSON Schema is a vocabulary for describing exactly that: which fields are required, what type each field must be, allowed value ranges, string patterns, and more. A JSON Schema is itself written in JSON, and tools like AJV can validate a document against a schema at high speed.

A dedicated JSON Schema Validator and Generator are on our roadmap — see what's coming next.

13. Security considerations

JSON is generally safer to parse than formats that allow executable code, but a few practices matter:

  • Never use eval() to parse JSON. Because JSON is a subset of JavaScript syntax, it's tempting to parse it with eval() — but this executes arbitrary code and is a serious security risk if the JSON comes from an untrusted source. Always use JSON.parse() or your language's dedicated JSON parser.
  • Sanitize before rendering. If you render values from untrusted JSON into HTML, escape them properly to prevent cross-site scripting (XSS) — JSON itself doesn't protect against this.
  • Watch for prototype pollution. In JavaScript, naively merging untrusted JSON into an object can allow keys like __proto__ to pollute the object prototype. Use safe merge utilities or validate keys when merging untrusted data.
  • Set size limits. APIs that accept JSON should enforce a maximum payload size to prevent denial-of-service attacks from extremely large or deeply nested documents.

14. Best practices for designing JSON APIs

  • Use consistent casing for keys throughout your API — typically camelCase for JavaScript-facing APIs or snake_case for others, but pick one and stick to it.
  • Represent dates as ISO 8601 strings, and always include a timezone or use UTC consistently.
  • Avoid deeply nested structures where a flatter shape would do — deep nesting makes both parsing and querying harder.
  • Use null deliberately to mean "explicitly no value," and omit a key entirely when a field is simply not applicable.
  • Version your API responses so structural changes don't silently break existing clients.
  • Document your JSON shapes with a JSON Schema so consumers of your API know exactly what to expect.

15. Advanced concepts

JSON Pointer (RFC 6901) defines a string syntax, like /address/city, for referencing a specific value inside a JSON document — useful for error messages and partial updates.

JSON Patch (RFC 6902) builds on JSON Pointer to describe a sequence of operations (add, remove, replace, move, copy, test) that transform one JSON document into another — commonly used for efficient partial updates in REST APIs.

JSON Lines / NDJSON is a convention (not part of the JSON spec itself) where each line of a file is a complete, independent JSON value. It's popular for logs and streaming data because a consumer can process the file line by line without loading the whole thing into memory.

Streaming parsers — for JSON documents too large to load into memory at once, streaming (or "SAX-style") parsers emit events as they encounter each token, rather than building the entire parsed structure up front.

16. Conclusion

JSON's staying power comes from being just complex enough to represent real-world structured data, and simple enough that a parser fits in a few hundred lines of code in any language. Whether you're debugging an API response, writing a configuration file, or designing a new service from scratch, understanding JSON's syntax rules, data types, and common pitfalls will save you time — and our Validator, Formatter, Repair, and Viewer tools are built to handle the mechanical parts so you can focus on your data.