You paste a response into your code, run it, and the parser stops with a message such as unexpected character or unexpected token. The data looked fine. It was almost certainly one stray character.
JSON is deliberately strict. Its grammar is small, which is why nearly every programming language can read it, but the same strictness means a single misplaced comma makes the whole document invalid. The good news is that most JSON errors come from the same handful of mistakes. This guide walks through the eight most common causes of invalid JSON, shows what each one looks like, and explains how to fix it, using the JSON specification (RFC 8259) and Mozilla's documentation as the source of truth.
If you are in a hurry, check these first: trailing commas, single quotes, unquoted keys, comments, and mismatched brackets. Those are the usual suspects.
What makes JSON valid?
JSON is a text format for structured data. Mozilla describes it as following JavaScript object syntax with extra restrictions: any JSON is a valid JavaScript literal, but not every JavaScript object literal is valid JSON. That one-way relationship explains most errors, because code that works as a JavaScript object often breaks as JSON.
Keep the following rules in mind and the eight errors below will look familiar.
- A document is built from objects in curly braces, arrays in square brackets, strings, numbers, true, false, and null.
- Strings and property names must use double quotation marks.
- Commas go between items, never after the last one.
- The literal names true, false, and null must be lowercase.
- There are no comments, no undefined, no NaN or Infinity, and no functions.
Why is JSON so strict?
It can feel pedantic that one comma invalidates a whole file, but the strictness is what makes JSON portable. Because the grammar is tiny and unambiguous, a document written by a Python script can be read by a JavaScript front end, a mobile app, and a database without any of them guessing what a missing quote or an extra comma was supposed to mean. Formats that tolerate sloppy input push the guessing onto every reader, and different readers guess differently.
That is also why a lenient tool can mislead you. Some editors and viewers quietly accept trailing commas or comments in JSON-like files. A file that opens without complaint in one tool can still be rejected by the strict parser in your application, so always test with the parser that will actually consume the data.
1. Trailing commas
This is the most frequent error. JavaScript, Python, and many other languages allow a comma after the last item in a list or object, so people carry the habit into JSON. In JSON it is invalid: {"name": "Ada", "age": 36,} fails because of the comma before the closing brace.
RFC 8259 defines a comma as a separator between one value and the next, so something must always follow it. Mozilla lists trailing commas first among the causes of the JSON.parse SyntaxError, and Firefox reports them with a message like unexpected character at line 1 column 14 of the JSON data. The fix is to delete the comma before the closing } or ].
2. Single quotes instead of double quotes
JSON strings must start and end with a double quotation mark. {'name': 'Ada'} is valid JavaScript but invalid JSON, because RFC 8259 defines the quotation mark as the double-quote character only.
Replace every single quote that delimits a key or a string value with a double quote. Apostrophes inside text, as in it's or don't, are fine as long as the string itself is wrapped in double quotes.
3. Unquoted property names
In JavaScript you can write {name: "Ada"}. JSON requires {"name": "Ada"}, with every property name written as a double-quoted string. This error often appears when someone copies an object from source code or a console log instead of from real JSON output.
Mozilla documents the Firefox wording for this family of mistakes as expected property name or } at a given line and column. Wrap each key in double quotes and the error disappears.
4. Comments
JSON has no comment syntax. Neither // nor /* */ is allowed, and Mozilla states plainly that comments are not allowed in JSON. Configuration files are where this bites, because people naturally want to annotate settings.
Remove the comments, or store the explanation in a separate field such as a note key, or keep documentation in a README. Some tools read formats that extend JSON with comments, often called JSONC or JSON5, but those are different formats, and a strict JSON parser will reject them.
5. Invalid numbers
JSON numbers are stricter than they look. RFC 8259 does not allow leading zeros, so 01 is invalid and 1 is correct. A decimal point must be followed by digits, so 1. fails while 1.0 works. Values such as NaN and Infinity cannot be represented at all.
Mozilla documents Firefox messages for these cases, including unterminated fractional number and expected , or } after property value in object. If a value such as a ZIP code or product code must keep its leading zeros, store it as a string rather than a number.
A related trap is size. RFC 8259 notes that integers between -(2^53)+1 and (2^53)-1 are interoperable, meaning every implementation agrees on their exact value. Larger numbers may be rounded by some parsers, so identifiers beyond that range are safer as strings.
6. Wrong literal values: True, None, and undefined
The literal names are true, false, and null, in lowercase, and RFC 8259 says no other literal names are allowed. Python's True, False, and None, JavaScript's undefined, and capitalized variants such as Null are all invalid.
This usually happens when someone prints a Python dictionary and pastes it as JSON instead of serializing it properly. Generate JSON with a serializer (json.dumps in Python, JSON.stringify in JavaScript) rather than printing objects. Be aware that JSON.stringify also quietly drops or rewrites values JSON cannot hold: undefined, functions, and symbols are omitted from objects or become null in arrays, and NaN and Infinity become null.
7. Unescaped characters inside strings
Inside a JSON string, a double quote must be escaped with a backslash, and raw control characters such as a literal line break or tab are not allowed. The text "He said "hi"" is invalid, while "He said \"hi\"" is valid.
A string that spans several lines must use the escape sequence backslash-n rather than an actual new line. Mozilla lists bad control character in string literal and bad Unicode escape among the messages for these problems, so if you see either, look for a raw tab, a raw line break, or a malformed escape inside a string.
8. Truncated, mismatched, or non-JSON data
Sometimes the syntax is fine but the data is incomplete or not JSON at all. A missing closing brace or bracket, an extra one, or a response cut off by a timeout all produce unexpected end of data style errors.
Another very common cause is receiving an HTML page (an error page, a login screen, or a redirect) where your code expected JSON. The parser then complains about the first character, usually a less-than sign, because HTML starts with a tag. If the error points at the very first character, print the raw response and check what you actually received, including the HTTP status code.
Also check encoding. RFC 8259 requires JSON exchanged between systems to be encoded as UTF-8, and a different encoding, or an unexpected invisible character at the start of a file, can trip up a parser.
Worked example: fixing a broken document
Here is a short document with five separate problems: {'id': 007, name: "Ada", "active": True, "tags": ["math", "code",]}. A parser stops at the first error it finds, so you would normally discover these one at a time, fixing one and running again. Tools that report several errors at once save a lot of that back and forth.
The corrected document is {"id": "007", "name": "Ada", "active": true, "tags": ["math", "code"]}. Each change maps to one of the errors above, as follows.
- The single quotes around id are replaced with double quotes, giving "id".
- 007 has a leading zero, so it cannot be a JSON number. If the zeros mean something, as they do in a code or a ZIP code, it becomes the string "007"; if they do not, it can simply be the number 7.
- The unquoted key name is wrapped in double quotes, giving "name".
- The capitalized True becomes the lowercase literal true.
- The trailing comma after "code" is deleted.
A fast way to debug any JSON error
When the cause is not obvious, work through the same sequence every time. It turns a vague error into a specific location.
A caution about validators: JSON often contains tokens, customer records, or internal data. Pasting it into a random website sends it to someone else's server. Prefer a validator that runs entirely in your browser or the one built into your editor, and confirm in your browser's Network tab that nothing is being sent if you are unsure.
- Read the position. Most parsers report a line and column or a character offset. The real problem is often just before it, such as the comma that precedes an unexpected closing bracket.
- Format the document. Indentation makes mismatched brackets and missing commas visible. In JavaScript, JSON.stringify(value, null, 2) indents output by two spaces; Mozilla notes the space argument accepts a number up to 10 or a string.
- Shrink the problem. Delete half of the document and test again, repeating until the broken part is small enough to see.
- Validate with the parser you actually use. Different languages and browsers word the same error differently, so test where the failure happens.
- Fix the source, not the symptom. If your code builds JSON by joining strings, switch to a serializer so quotes and commas are always correct.
Practical checklist
- Use double quotes for every key and string value.
- Remove trailing commas before } and ].
- Delete comments, or keep notes in a separate field or file.
- Write true, false, and null in lowercase; never True, None, or undefined.
- Avoid leading zeros, and store identifiers that need them as strings.
- Escape double quotes and line breaks inside strings.
- Generate JSON with a serializer instead of building it by hand.
- Validate sensitive JSON locally rather than pasting it into unknown websites.
Research and references
This guide was prepared from the authoritative references below.
