Quick answer
Most JSON syntax errors come from a small group of issues: single quotes, trailing commas, missing commas, mismatched braces or brackets, and invalid string escapes. Fix one reported issue at a time and validate again.
Key takeaways
- JSON strings use double quotes.
- Trailing commas are invalid.
- Braces and brackets must balance.
- The reported error position can be slightly after the real mistake.
Single quotes and unquoted keys
JavaScript object literals can sometimes use single quotes or unquoted property names, but standard JSON cannot. Both object keys and string values must use double quotes. This is a common source of confusion when data is copied from source code into an API request or configuration file.
Trailing and missing commas
Items in an object or array are separated by commas, but there is no comma after the final item. A trailing comma that is accepted by some programming languages will make strict JSON invalid. Missing commas create the opposite problem: the parser reaches the next key or value before the previous item has been properly separated.
Mismatched structures
Every opening brace must have a matching closing brace, and every opening bracket must have a matching closing bracket. In deeply nested data, indentation makes these pairs much easier to inspect. A parser error can help you locate the point where the structure stops making sense.
String escaping
Quotes, backslashes and some control characters inside a JSON string must be escaped. A raw line break inside a quoted string, for example, is not valid JSON. When debugging, fix the first parser error and validate again because one syntax problem can make several later tokens appear incorrect.
Read parser errors as clues, not perfect diagnoses
A parser reports the point where it can no longer continue, which can be slightly after the actual mistake. If an error points at a property name, inspect the token immediately before it: a missing comma or closing quote in the previous value may be the real cause.
Fix the earliest error first and parse again. One broken string can make many later lines appear invalid, so trying to fix every highlighted token at once often wastes time.
Escapes inside strings
A double quote inside a JSON string must be escaped, as must a literal backslash when it is meant to be data. Control characters such as newline are represented with escape sequences rather than raw line breaks inside a quoted string.
When JSON is embedded inside another language or shell command, there can be a second layer of escaping. Debug the JSON by itself before debugging the surrounding command.
Numbers have rules too
JSON numbers are not quoted, and values such as `NaN` or `Infinity` are not part of standard JSON. Leading plus signs and some language-specific numeric notations are also invalid even though a programming language may accept them elsewhere.
If an API needs a special value, check its documentation; it may expect a string or `null` instead of a non-standard number token.
A disciplined troubleshooting workflow
Reduce a failing payload to the smallest example that still triggers the parser error. Validate that smaller piece, restore one section at a time, and keep formatting consistent. This isolates the problem much faster than staring at a one-line payload containing thousands of characters.
Once syntax is valid, move on to API-level validation. A 400 response after successful parsing may be a schema or business-rule problem rather than a JSON problem.
Separate syntax debugging from API debugging
Once the JSON parses successfully, stop changing punctuation and inspect the contract expected by the receiving system. A server can reject perfectly valid JSON because a required property is absent, a field has the wrong type, an enum value is unsupported or the authenticated user is not allowed to perform the action. Those are application problems rather than JSON syntax errors.
Keeping these layers separate makes troubleshooting faster. First prove that the text is valid JSON, then validate the shape of the data, and finally investigate the remote service response. Changing all three layers at once makes it difficult to know which fix actually solved the problem.
Frequently asked questions
Why does the error point after the real mistake?
The parser often notices the problem only when it reaches a token that cannot legally follow the broken one.
Can I use single quotes in JSON?
No. Standard JSON strings and object keys use double quotes.
Is NaN valid JSON?
No. Standard JSON supports ordinary numbers but not NaN or Infinity tokens.
Putting the guidance into practice
For common json errors and how to fix them, the most reliable approach is to define the purpose first, keep the original input or source available, perform one controlled change at a time, and verify the result before it is copied into a production workflow. This reduces accidental errors and makes the process easier to reproduce later. A browser utility can remove repetitive arithmetic or formatting work, but the user still decides whether the inputs and interpretation match the real task.
If the result from common json errors and how to fix them will affect a customer, financial record, technical deployment, formal submission or other important outcome, add a second check using the destination system or an authoritative source. This is not because a simple tool is inherently unreliable; it is because real workflows often contain rules that are outside the calculation itself. Keeping that boundary visible is a practical professional habit.
Try the related tool
Apply the idea directly with the JSON Formatter & Validator. The tool page explains its inputs, limitations and privacy behavior.