“Unexpected token < in JSON at position 0”: what it means and how to fix it

“Unexpected token < in JSON at position 0” means code tried to parse a response as JSON, but its first character was <, the start of an HTML page. The server sent HTML instead, usually a 404 or 500 error page, a login redirect or the site’s home page. Look at the raw response to see which.

Reading the error

JSON must start with {, [, a quote, a number, or true, false or null. “Position 0” is the first character. A < there is almost always <!DOCTYPE html> or <html>. Newer browsers word the same failure differently, for example “Unexpected token '<', "<!DOCTYPE "... is not valid JSON”. Related variants point to the same family of problems:

• Unexpected end of JSON input — the response was empty, often a 204 No Content or a failed request.
• Unexpected token u — the code parsed the text undefined, meaning a variable was never set.
• Unexpected token o — the code called JSON.parse on something that was already an object, which turns into the text [object Object].

See what actually came back

1. Open the browser’s developer tools (F12) and the Network tab, then trigger the request again.
2. Click the request. Check the status code and the Content-Type header.
3. Open the Response tab. If it begins with <!DOCTYPE html>, read the page — it usually says what went wrong.

In code, read the body as text first and log it before parsing, so the error tells you what you received instead of hiding it. Tools such as curl show the same raw response from the command line, outside the browser, which rules out browser extensions and cached pages.

The usual causes

• Wrong URL. A typo, a missing /api prefix or a relative path resolved against the wrong page returns the site’s 404 page. Many single-page apps return their index.html for every unknown path, with status 200, which makes this hard to spot.
• Server error. The API crashed and the framework sent an HTML error page with status 500. Check the server logs.
• Not logged in, or session expired. The request was redirected to a login page. The status may be 200 after the redirect.
• Development proxy not set up. In local development the front-end server answers/api/... itself, with its own HTML, because the request never reached the API.
• A firewall, captive portal or maintenance page intercepted the request and returned its own HTML.

Fixing it properly

1. Fix the root cause above: the URL, the server error, the authentication or the proxy.
2. Make the client check before parsing: confirm the response status is OK and that the Content-Type contains application/json. If not, show the status and the start of the body in the error message.
3. Make the API return JSON errors, such as {"error": "Not found"} with status 404, rather than HTML pages, so clients can handle them.

When the JSON itself is broken

If the response really is JSON but parsing fails at a later position, the problem is in the data: a trailing comma, single quotes, a comment or an unescaped character. Paste the body into the JSON Validator, which explains the likely cause at the exact position, or the JSON Formatter to indent it and see its structure. Both run in your browser, so API responses with real data stay private. For the full list of syntax errors, see how to fix invalid JSON.

Mistakes to avoid

• Wrapping the parse in try/catch and ignoring the error, which hides the real failure.
• Assuming status 200 means JSON; redirects and catch-all routes return 200 HTML.
• Calling JSON.parse on data your HTTP library has already parsed.

Checklist

• Raw response inspected in the Network tab?
• Status code and Content-Type checked?
• URL, authentication and proxy correct?
• API returns JSON for errors too?