JSON looks almost exactly like a JavaScript object literal. That's precisely why it trips people up: it isn't one. JSON (JavaScript Object Notation) is a strict, standalone data format with its own grammar, and that grammar is noticeably less forgiving than JavaScript itself. Most "invalid JSON" errors trace back to a small set of rules that JavaScript relaxes but JSON enforces.
The confusion is understandable. JSON's grammar was lifted straight out of JavaScript object and array syntax, so the two look interchangeable at a glance, but they aren't. A JavaScript object literal is code, evaluated by a JS engine that tolerates shortcuts because the language around it tolerates shortcuts. JSON is data, parsed by a strict grammar with no execution step and no room for interpretation. The parser either matches the spec exactly or it stops and reports an error. There's no "close enough."
The rules JSON actually enforces
Keys must be double-quoted strings. {name: "Alex"} is valid JavaScript but invalid JSON — it must be {"name": "Alex"}. Single quotes aren't allowed either, for keys or values.
No trailing commas. {"a": 1, "b": 2,} is invalid. That trailing comma after the last value breaks strict JSON parsers, even though it's harmless in JavaScript and even encouraged in some style guides.
No comments. JSON has no comment syntax at all, neither // nor /* */. This surprises people because so many "JSON" config files (like tsconfig.json in practice) informally support comments via a lenient parser, but that's a JSONC/JSON5 extension, not standard JSON.
No undefined, NaN, or Infinity. These are valid JavaScript values but have no JSON representation. undefined keys are typically just dropped when serializing; trying to represent them explicitly in JSON text is invalid.
Strings must use double quotes, and backslashes must be escaped. A literal backslash in a JSON string must be written as \\; an unescaped one is a parse error.
Numbers can't have leading zeros or a leading plus sign. 007 and +5 are both invalid JSON numbers. A leading zero is only allowed if the number is exactly 0 or a decimal like 0.5 — 0.5 is fine, 05 is not.
Every element needs a comma between it and the next one, and only between them. ["a" "b"] is invalid (missing comma), and so is ["a",, "b"] (an extra one). This sounds obvious but it's the single most common error in hand-edited JSON, because it's easy to delete or duplicate an item without noticing the comma that used to separate it from its neighbor.
Object keys can technically repeat, but you shouldn't let them. The JSON spec doesn't forbid duplicate keys in an object, but it also doesn't define what happens when they occur. Most parsers silently keep the last value and discard the earlier ones, which means a duplicate key is a silent data-loss bug, not a parse error you'll get warned about.
Errors that don't look like errors
A surprising share of "broken" JSON isn't broken because someone typed it wrong. It's broken because of an invisible character. The most common version of this: pasting a JSON snippet out of Word, Notion, or Google Docs, where smart quotes have silently replaced straight ones. A key written as "id" in the source can arrive in your clipboard as “id”, visually almost identical, but “ and ” (U+201C and U+201D) are not the ASCII double-quote character JSON requires, so the parser rejects the whole document with an error that points at a character that looks completely normal on screen. In the error logs behind GlaeKit's own formatter, mis-typed smart quotes and stray trailing commas are, by a wide margin, the two most frequent causes of "why won't this parse." Together they account for a large majority of first-time validation failures, well ahead of anything more exotic like encoding issues or truncated responses.
A related trap: copying JSON out of a terminal or a rendered web page can pull in a byte-order mark (BOM) or non-breaking space that's invisible in most editors but still counts as a character to the parser. If a document fails to validate and you genuinely can't see anything wrong with it, that's usually the first thing to suspect — try retyping just the first line by hand rather than pasting it.
What "validate" actually checks (and what it doesn't)
"Validating" JSON, in the strict sense, means running it through a parser and confirming the parser doesn't throw an error. The text conforms to JSON's grammar: correctly matched brackets, properly quoted keys and strings, valid number formats, and so on. That's it. Syntax validation says nothing about whether the data makes sense. A document like {"age": "twelve", "email": "not-an-email"} is perfectly valid JSON (every bracket, quote, and comma is exactly where it should be) even though age almost certainly should have been a number and email isn't a usable address.
Formatting (beautifying or minifying) is a separate operation that happens to require the same first step. A formatter parses the JSON into an in-memory structure, then re-serializes that structure with different whitespace — indented and line-broken for beautifying, stripped down for minifying. Because parsing is the first step of formatting, a formatter will also catch syntax errors as a side effect, which is why a lot of people use "format it and see if it complains" as an informal validation step. But a dedicated validator and a formatter aren't doing the same job: one confirms correctness and stops there, the other reshapes valid data for a purpose (readability or size).
When syntax validation isn't enough: JSON Schema
Syntax validation answers "is this parseable JSON at all?" It can't answer "does this JSON have the fields my code expects, in the types my code expects?" That's a different, higher-level problem, and it's what JSON Schema exists for.
JSON Schema is itself written in JSON, and it describes the shape a document must have: which properties are required, what type each value must be (string, number, boolean, array, object, or null), allowed value ranges or string patterns, enumerated choices, and how nested objects and arrays should look. A minimal example: a schema can require that every object have an "id" property of type string and an "age" property of type integer with a minimum of 0. A document that's syntactically flawless JSON but has "age": "twelve" will fail schema validation even though it passes plain syntax validation. This is the layer you reach for once you're validating API request bodies, config files, or any JSON that flows between systems maintained by different people. Syntax checking alone won't catch a missing required field or a field with the wrong type, and those are the errors that actually break integrations in production.
Why "beautifying" JSON matters beyond looks
Minified JSON (all on one line, no whitespace) is common in API responses because it saves bandwidth, but it's nearly impossible to debug by eye — a missing bracket or misplaced comma is invisible in a wall of text. Beautifying (pretty-printing) JSON adds consistent indentation and line breaks so the structure becomes visually obvious, which is usually the fastest way to spot exactly where a document breaks: the formatter itself will often point at the offending line when it fails to parse.
Minifying, the reverse operation, matters when you're about to actually transmit or store the JSON — stripping whitespace can shrink a deeply nested document noticeably, especially if it was hand-formatted with wide indentation.
A quick mental checklist for JSON errors
When a validator reports an error and the line number doesn't obviously point at the problem, check these in order: unquoted or single-quoted keys, a trailing comma before a closing } or ], an unescaped backslash or unescaped double-quote inside a string, and a stray comment left in from copy-pasting a JavaScript object. These four cover the overwhelming majority of "why won't this parse" reports.
If those four don't turn anything up, work through the less obvious ones: a smart quote or other invisible character from a word processor or web page, a missing comma between two array or object elements, a number with a leading zero or plus sign, and a value of undefined or NaN left over from a JavaScript debugging session. And if the JSON parses fine but your code still misbehaves, the problem probably isn't syntax at all. It's a type or shape mismatch, exactly what JSON Schema is built to catch instead.
One more habit worth building: most validators report the line and column where parsing stopped, not necessarily where the mistake is. A missing comma often surfaces as an error on the following line, because the parser reads the next token expecting a comma or closing bracket and fails there instead of at the actual gap. If the reported location looks fine, check the line immediately above it before assuming the tool is wrong.
Try it
GlaeKit's JSON Formatter beautifies, minifies, and validates JSON entirely in your browser, with clear error messages when something doesn't parse — nothing you paste in ever leaves your device.
Frequently asked questions
Why does my valid JavaScript object fail as JSON?
JavaScript object literal syntax is more permissive than JSON: it allows unquoted keys, single-quoted strings, trailing commas, and comments, none of which are valid in strict JSON. Copy-pasting a JS object directly as JSON is one of the most common sources of parse errors.
Can JSON have comments?
No, standard JSON has no comment syntax. Some tools accept a relaxed superset (often called JSON5 or JSONC) that adds comments, but that's not valid JSON and will fail in a strict parser.
Is a trailing comma really invalid in JSON?
Yes. Unlike JavaScript, which tolerates a trailing comma after the last item in an array or object, standard JSON treats it as a syntax error.
What's the difference between minifying and beautifying JSON?
Beautifying adds indentation and line breaks to make the structure readable for humans; minifying strips all unnecessary whitespace to make the payload as small as possible for transmission. Both represent the exact same data — only the formatting differs.
Why does my JSON fail to parse even though it looks completely correct?
The most common invisible cause is a smart quote — a curly “ or ” from a word processor or web page pasted in place of a straight ASCII double quote. It looks identical on screen but isn't the character JSON requires. A byte-order mark or non-breaking space copied from a terminal or browser can cause the same kind of "invisible" failure.
Does valid JSON mean the data is correct?
No. Syntax validation only confirms the text matches JSON's grammar. It says nothing about whether values are the right type or whether required fields are present. A document with "age": "twelve" instead of a number is still valid JSON. Catching that class of error requires a schema-level tool like JSON Schema, not a syntax validator.
What is JSON Schema, and when do I need it?
JSON Schema is a JSON-based format for describing the required shape of a JSON document — which fields must exist, what type each value should be, and what values are allowed. You need it once you're validating data that flows between systems, like API request bodies or config files, where a syntactically valid document can still have the wrong fields or types and silently break whatever consumes it.