Why Is My JSON Invalid?
Updated August 30, 2026
A parser rejected your JSON and handed you something like “Expected double-quoted property name at position 7”. That names the place, not the cause. Here is what it is almost always telling you.
The short answer
Five mistakes account for nearly every invalid JSON file, and all five come from writing JSON the way you would write JavaScript:
- A trailing comma after the last item. Legal in JavaScript, never in JSON.
- Single quotes around a string or key. JSON uses double quotes only.
- An unquoted key. Keys are strings, so they need quotes too.
- A comment. JSON has no comment syntax at all.
- A JavaScript-only value — NaN, Infinity, or undefined. None exist in JSON; use null.
Why JSON is stricter than it looks
JSON began as a subset of JavaScript, which is exactly why it trips people up: it looks like a language you already know, so you write what looks right rather than what the grammar allows. The grammar is deliberately tiny — objects, arrays, strings, numbers, true, false, null — with no comments, no variables, no trailing commas, and no way to write a value that isn't one of those seven things.
That strictness is the point. A format with no optional syntax parses identically everywhere, which is why JSON travels between languages at all. The cost is that one stray character stops the whole document.
One consequence catches people out: a file saved with a byte-order mark — an invisible character some Windows editors add at the very start — fails immediately, because the parser meets a character before the opening brace. The file looks perfect on screen and still won't parse.
What the error messages actually mean
The wording comes from the browser's own JSON engine, so the same broken file reads differently in Chrome, Firefox, and Safari. These are Chrome's, which are also what you see in Node:
| The message | What it usually means |
|---|---|
| Expected double-quoted property name | A trailing comma — the parser expected another key after it |
| Expected property name or '}' | A key that isn't a double-quoted string: single quotes, no quotes, or curly “smart” quotes pasted from a document |
| Expected ',' or '}' after property value | Something unaccounted for after a value — most often a comment, or a missing comma |
| Unexpected token 'N', 'I', or 'u' | NaN, Infinity, or undefined used as a value |
| Unexpected number | A number JSON won't accept — a leading zero like 01, or hex like 0x1F |
| Unexpected end of JSON input | A brace or bracket is never closed; the document stops mid-structure |
Finding the character it means
Chrome reports a character offset — “position 7” — which is no help in a file of any size. The JSON Formatter converts that offset into a line and column and shows you the offending line, so you can go straight to it. Nothing is uploaded; the parsing happens in the page.
Two habits make the rest easy. Format the document first, because a minified file is one enormous line and every error lands on line 1. And fix only the first error before re-checking: one missing brace makes the parser misread everything after it, so later errors are often phantoms that disappear on their own.
What a validator can't tell you
Valid is not the same as correct, and two problems pass every syntax check in silence.
Duplicate keys are legal. An object with the same key twice parses without complaint, and the last one wins — the earlier value is gone with no warning. If a config setting seems to be ignored, search the file for a second copy of that key.
Large integers lose precision. JSON has one number type, and JavaScript reads it as a double. An ID like 12345678901234567890 comes back as 12345678901234567000. Nothing errors; the digits are simply wrong. That is why APIs dealing in large IDs usually send them as strings, and why you should keep them that way.
Neither is a bug in the parser or in this tool — both are JSON behaving as specified. A formatter tells you whether a document is well-formed. It cannot tell you whether it says what you meant.
Common questions
- Can JSON have comments?
- No. The format has no comment syntax, and adding one invalidates the whole document. If you need notes in a config file, use a format that allows them, such as YAML, or add an ordinary key like "_comment" that your program ignores.
- Why does my JSON work in JavaScript but not in a JSON parser?
- Because a JavaScript object literal is a much looser thing than a JSON document. Trailing commas, single quotes, unquoted keys, and comments are all fine in JavaScript source and none are valid JSON. Anything that travels between systems has to satisfy the stricter grammar.
- Are duplicate keys allowed in JSON?
- The syntax permits them, so a validator passes the document. JavaScript's parser keeps the last value and discards the earlier ones silently. Treat a duplicate key as a bug even though nothing reports it as one.
- Why did my long ID number change?
- JSON has a single number type, and JavaScript reads numbers as doubles, which hold roughly 15 to 17 significant digits. Anything longer is rounded on the way in, with no error raised. Send large identifiers as strings instead.
- Is it safe to paste private JSON into an online formatter?
- It depends on the tool. Many send your text to a server to process it. This one parses it in your browser using the built-in JSON parser, so config files, tokens, and API responses stay on your device — you can confirm that in your browser's network tab.