Invalid JSON: The Common Errors and How to Fix Them

A deploy fails, an API client reports an unexpected token, and the JSON file looks perfectly fine. JSON is a small format with strict rules, and most parse errors come from a handful of habits carried over from JavaScript, Python or hand-edited configuration files. This guide lists those mistakes, shows how to locate them in seconds and explains the number and structure problems that a plain syntax check cannot catch.

Why JSON is stricter than it looks

JSON (JavaScript Object Notation) is defined by RFC 8259. It resembles a JavaScript object literal but allows far less. A valid document is a single value: an object, an array, a string, a number, true, false or null. Everything else is rejected.

• Strings and property names must use double quotes.
• Comments of any kind are not allowed.
• There is no trailing comma after the last item.
• The values undefined, NaN and Infinity do not exist.
• Numbers have no leading zeros, no plus sign and no hexadecimal form.

Parsers are not being picky for the sake of it. Because the rules are tiny and identical everywhere, a file written by a Java service parses the same way in a browser, a phone app or a shell script.

The mistakes behind most parse errors

1. Trailing comma. A list such as ["a", "b",] or an object that ends with a comma is fine in JavaScript and invalid in JSON. It usually appears after someone deletes the last line of a block.
2. Single quotes. {'name': 'Ada'} is a Python or JavaScript habit. Both keys and string values need double quotes.
3. Unquoted keys. {name: "Ada"} works as a JavaScript object but not as JSON.
4. Comments. Neither double-slash comments nor block comments are allowed, which is why configuration that needs notes often lives in YAML instead.
5. Values JSON does not have. undefined, NaN and Infinity must become null or a string.
6. Malformed numbers. 007 and +5 are invalid; write 7 and 5. A decimal point needs digits on both sides.
7. Raw line breaks inside strings. A string cannot contain a real new line or tab. They are written as escape sequences, a backslash followed by n or t, and a backslash that does not start a valid escape also fails.
8. Invisible characters. A byte order mark at the start of a file, or a curly quote pasted from a document, looks fine on screen and still breaks the parser.

Find the error in seconds

The JSON Validator checks strict JSON syntax as you paste. When something is wrong it shows the line and column of the first error, prints the offending line with a caret under the position and adds a plain-English hint for the common cases above, such as trailing commas, single quotes, unquoted keys and comments. When the document is valid it summarizes what it found: whether the root is an object or an array, how many keys, objects and arrays it contains, how deeply they nest and its size in bytes.

1. Paste the JSON, or load the example that contains an error to see how a report looks.
2. Read the line, column and hint, then fix that one problem.
3. Check again. Only the first error is reported, so a file with three mistakes needs three passes.

Nothing is uploaded. The check runs in your browser, which matters when the file holds tokens or customer data.

Format it so people can read it

Minified JSON is efficient for machines and painful for humans. Paste it into the JSON Formatter to get indented output with 2 spaces, 4 spaces or tabs, and optionally sort the keys alphabetically, which makes two versions of a file much easier to compare. The same tool can minify, and the JSON Minifier is there when shrinking a payload is the whole goal. Invalid input is reported with its line and column instead of being silently changed.

To see what changed between two responses, use the JSON Diff Checker. It compares structure rather than text, so key order and whitespace do not matter, and it lists each added, removed and changed value with its path, for example $.address.city. Arrays are compared position by position, so inserting one item near the top of a list marks every later item as changed. Keep that in mind when a long list looks wildly different.

Numbers and identifiers that change silently

Valid JSON can still carry wrong data. JavaScript stores every number as a 64-bit floating-point value, so integers above 9,007,199,254,740,991 lose precision. The value 9007199254740993 comes back as 9007199254740992, with no error at all. Numbers with more than 15 or 16 significant digits behave the same way in any JavaScript-based tool, including the formatter above.

Valid is not the same as correct

A syntax check answers one question: is this JSON? It cannot know whether age should be a number, whether email is required or whether a date follows a pattern. To check structure against rules, use the JSON Schema Validator. When your source data is XML, the XML to JSON Converter produces a JSON version, and for configuration that needs comments, the YAML Formatter cleans up and validates YAML.

Responses often carry encoded values too. If a field holds a JWT or a Base64 blob, Base64, hashing and encryption: what each one actually does explains how to read them safely.

A short checklist

• Double quotes everywhere, and no quotes around numbers you want to calculate with.
• No comma after the last item, no comments, no undefined or NaN.
• Escape line breaks inside strings.
• Send very large IDs as strings.
• Validate syntax first, then format, then diff, then check structure with a schema.