How to fix "Unexpected token" JSON errors

"Unexpected token" is the message a JSON parser gives when it reaches a character that is not allowed at that point. The exact wording depends on your browser, runtime or language, but the meaning is always the same: the text is not valid JSON, and the parser stopped at the first character it could not accept. This guide lists the mistakes that cause most of these errors and a quick way to find the one in your data.

Read the error first

Most parsers tell you two things: the character they did not expect, and where it is, as a position (a count of characters from the start) or as a line and column. The problem is usually at that spot or just before it. Paste the text into the JSON Formatter & Validator and it shows the line and column, so you do not have to count characters by hand.

If the unexpected character is at the very start (position 0, line 1, column 1), the text is probably not JSON at all. Look at what you actually received before you look for a typo.

The common causes

1. An HTML page instead of JSON. An error that complains about < at the start almost always means the server returned an HTML page, such as an error page, a login page or a "not found" page. Check the status code and the Content-Type header of the response, and read the body as text.
2. An empty response. "Unexpected end of JSON input" means the parser ran out of text. The body was empty (for example a 204 No Content response) or the download was cut off.
3. A trailing comma. {"a": 1,} and [1, 2,] are allowed in JavaScript code but not in JSON. Remove the comma before the closing bracket.
4. Single quotes. JSON strings and keys must use double quotes. {'a': 'b'} is not JSON.
5. Keys without quotes. {a: 1} is a JavaScript object literal, not JSON. Every key must be a string in double quotes.
6. Comments. JSON has no comments. Remove // and /* */ lines, or use a format that allows them for configuration files.
7. Values JSON does not have. undefined, NaN, Infinity, dates written as new Date(...) and functions are not JSON values. Use null, a number or a string instead.
8. Hidden or broken characters. A byte order mark at the start of a file, smart quotes pasted from a word processor, an unescaped line break inside a string, or a backslash that is not part of a valid escape (such as a Windows path written as C:\new) all break parsing.

A step-by-step way to find the problem

1. Look at the raw text, not a parsed object. Log or copy the response body exactly as received.
2. Check the first character. Valid JSON text starts with {, [, a double quote, a digit, a minus sign, or one of true, false and null.
3. Paste it into the JSON formatter and go to the reported line and column.
4. If the error is at the end, look for a missing closing bracket or brace, or a cut-off download.
5. For a large payload, remove half of it and check again, keeping the half that still fails, until the broken part is small enough to see.
6. Once it parses, use the API Payload Inspector to list every path and type, which helps when the JSON is valid but not the shape your code expects.

When the JSON is valid but your code still fails

Some errors come from parsing twice. If a value is already an object and your code calls the parser on it again, the object is first turned into the text [object Object], and the parser stops at the letter o. In the other direction, a JSON string that was encoded twice arrives as one long quoted string full of \" sequences. Parse it once, check the type, and parse again only if the result is still a string.

Also check the character encoding. JSON exchanged between systems should be UTF-8. If text arrives in another encoding, accented letters and symbols can turn into bytes the parser cannot read.

Webhooks and signed requests

If you parse a webhook body to fix a JSON error, keep the original raw bytes as well. A signature is computed over the exact bytes that were sent, and parsing and re-serialising the JSON changes them. The Webhook Debugging Helper shows the body as received and warns when its Content-Type says JSON but the body does not parse.

Preventing the error

• Create JSON with your language's serializer instead of joining strings by hand.
• Check the status code and Content-Type before you parse a response.
• Handle empty bodies on purpose instead of passing them to the parser.
• Keep configuration files that need comments in a format that supports them, and convert them to JSON when you build.

The rules above come from the JSON standard (RFC 8259), which defines the small set of values and the strict syntax every parser follows.