What Is JSON? Syntax Rules and How to Fix Common Errors

JSON (JavaScript Object Notation) is a text format for representing structured data as key-value pairs and ordered lists, built from just six value types. It’s the format nearly every web API uses to send and receive data, and it’s also common in config files, log lines, and NoSQL databases. Unlike a JavaScript object literal, which it superficially resembles, JSON has a small, strict set of rules, and violating any one of them makes the whole document unparseable.

What JSON actually is

Every JSON document is built from exactly six value types:

• String, double-quoted only, like "hello"
• Number, like 42 or 3.14
• Boolean, either true or false
• null
• Object, an unordered set of key-value pairs wrapped in {}
• Array, an ordered list of values wrapped in []

That’s the entire type system. There’s no date type, no undefined, no function type, nothing else. Objects and arrays can nest inside each other as deeply as needed, but every value at every level has to be one of those six.

The syntax rules that go along with those types are just as fixed:

• Object keys must be double-quoted strings. {"name":"Ada"} is valid; {name:"Ada"} is not.
• No trailing commas. The last property in an object and the last item in an array can’t have a comma after them.
• No comments of any kind, not // and not /* */.
• Strings and keys use double quotes only. Single quotes aren’t valid JSON syntax, even though they’re valid JavaScript.
• Keys can never be left unquoted, no matter how simple the name is.
• NaN, Infinity, and undefined aren’t valid JSON values, even though all three are valid in JavaScript.
• Functions can’t be represented in JSON. There’s no way to serialize behavior, only data.

Break any one of these and a JSON parser stops and reports an error rather than guessing at what you meant.

JSON vs. a JavaScript object literal

JSON’s {} and [] syntax was borrowed from JavaScript object and array literals, which is exactly why the two get confused. They look almost identical on the page, but a JavaScript object literal is more permissive on every point where JSON is strict:

Feature	JSON	JavaScript object literal
Keys must be quoted	Yes, double quotes only	No, quotes optional
Trailing comma allowed	No	Yes
Comments allowed	No	Yes
Single-quoted strings	No	Yes
Functions as values	No	Yes
undefined as a value	No	Yes

This is where a lot of debugging time goes. Copying an object literal straight out of a JavaScript file, unquoted keys, trailing comma and all, into a spot that expects JSON produces something that runs fine as JavaScript but fails the moment JSON.parse touches it. JSON isn’t a subset of JavaScript syntax you can write casually; it’s a separate, stricter format that happens to share punctuation with one.

Worked example: minifying and formatting a real API response

Take a typical user object an API might return:

{
  "id": 1,
  "name": "Ada Lovelace",
  "email": "[email protected]",
  "roles": [
    "admin",
    "user"
  ],
  "active": true,
  "meta": null
}

That pretty-printed version, with 2-space indentation, is 145 characters. The same data minified, with every space and line break stripped, is this:

{"id":1,"name":"Ada Lovelace","email":"[email protected]","roles":["admin","user"],"active":true,"meta":null}

That’s 107 characters, about 35% smaller, and the difference is purely whitespace. Not a single value or key changed; the data is identical.

This is why APIs send JSON minified over the wire: at scale, stripping that 35% of bytes across millions of requests adds up to real bandwidth and latency savings, and no client-side code needs the indentation to parse the value correctly. But that same minified string is close to unreadable to a human. If you’re debugging a response and need to see the nesting, the key names, and where an array starts and ends, you reformat it back to the indented version. Same data, two different jobs: one for machines, one for you.

Format your own JSON

Paste minified or messy JSON below to see it reformatted with proper indentation, or use it in reverse to minify a pretty-printed document before sending it somewhere size matters.

JSON Formatter, Beautifier & Validator

Free, no sign-up, works on any device.

Open the full tool

Common mistakes and edge cases

Trailing commas. Given {"id":1,"name":"Ada",}, V8 (the engine behind Chrome and Node.js) reports:

Expected double-quoted property name in JSON at position 21 (line 1 column 22)

The comma after "Ada" has nothing following it, and JSON has no concept of an optional trailing separator. Firefox’s SpiderMonkey engine phrases its errors differently, but the parse fails the same way in every JSON-compliant engine.

Unquoted keys. {id:1} fails with:

Expected property name or '}' in JSON at position 1 (line 1 column 2)

The parser expects a double-quoted string right after { and finds a bare identifier instead.

Single-quoted keys. {'a':1} hits the same error class:

Expected property name or '}' in JSON at position 1 (line 1 column 2)

Single quotes aren’t a valid way to open a string in JSON, so the parser treats 'a' exactly as it would treat an unquoted key: not a valid property name.

NaN and undefined as values. {"a":NaN} produces:

Unexpected token 'N', "{"a":NaN}" is not valid JSON

And {"a":undefined} produces:

Unexpected token 'u', "{"a":undefined}" is not valid JSON

Both are legal in a JavaScript object literal but have no representation in JSON. If a value can be NaN or undefined in your application, you need to convert it to null or a string before serializing.

Duplicate keys silently overwrite. {"a":1,"a":2} is syntactically valid JSON, no error at all, and parses to {"a":2}. Most parsers, including JavaScript’s, keep only the last occurrence of a repeated key and discard the earlier one without warning. This is a subtle source of real bugs: a build tool that concatenates config fragments, or a hand-edited file where someone pastes a block twice, can end up with the same key appearing twice, and because there’s no error, nobody notices until the wrong value shows up somewhere downstream.

Frequently asked questions

What is JSON? JSON (JavaScript Object Notation) is a text format for structured data, built from six value types: strings, numbers, booleans, null, objects, and arrays. It’s the most common format for API requests and responses, and it’s also used in config files and many databases.

Is JSON the same as a JavaScript object? No. JSON looks like a JavaScript object literal but is stricter: keys must be double-quoted, trailing commas aren’t allowed, comments aren’t allowed, and values like undefined or a function can’t be represented at all. A JavaScript object literal permits all of those; JSON permits none of them.

Why does a trailing comma break my JSON? Because JSON’s grammar has no rule for an extra comma after the last item in an object or array. A parser reading {"id":1,"name":"Ada",} expects another property name after the comma and instead finds the closing brace, which is exactly what the error “Expected double-quoted property name in JSON” is reporting.

Can JSON have comments? No. There’s no syntax for // or /* */ comments anywhere in the JSON specification. If you need to annotate a JSON file for humans, the usual workarounds are a separate documentation file, a sibling "_comment" key treated as ordinary data, or switching the file to a format that does support comments, like JSON5 or YAML.

What’s the difference between formatting and minifying JSON? Formatting (also called beautifying or prettifying) adds indentation and line breaks so a human can read the structure at a glance. Minifying strips all of that whitespace to produce the smallest possible string. Both represent the exact same data; the difference is purely presentation, and it’s common to convert between the two depending on whether the JSON is being read by a person or sent over a network.

Is my data sent to a server when I use an online JSON formatter? With pluri.tools’ JSON Formatter, no. Formatting, minifying, and validation all run with plain JSON.parse and JSON.stringify in your browser’s JavaScript engine. There’s no fetch or network call involved, so the JSON you paste never leaves your device.