Unexpected End of JSON Input: Causes and Fixes

Find the text that was actually parsed

The error is about the input to the parser, not necessarily the object you expected to receive. An empty string and a document ending halfway through a quoted value can both trigger it. Start by inspecting the exact response body or string passed to JSON.parse.

In browser developer tools, open the Network tab, select the request, and inspect its status, headers and response body. A successful request with no body may be intentional. A failed request may return plain text or HTML rather than the JSON your code expects.

JSON.parse("");              // no JSON value
JSON.parse('{"user":');     // value is incomplete
JSON.parse('{"user":null}'); // complete JSON

Handle empty HTTP responses explicitly

A 204 No Content response has no response body to parse. For other responses, read the text once so you can distinguish an empty body from malformed JSON. Check whether your API contract permits an empty response before deciding that it represents null.

Do not consume a response with both response.json() and response.text(). A response body is a stream; reading it twice is a different error. Pick one path, inspect what you received, and then parse it.

async function readJSON(response) {
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  if (response.status === 204) return null;
  const text = await response.text();
  if (!text.trim()) {
    throw new Error("Expected JSON but received an empty body");
  }
  return JSON.parse(text);
}

Check for truncated files and downloads

If the body begins with valid JSON and stops abruptly, compare the original response with the saved file. A cancelled request, partial log capture, or an interrupted write can leave only the beginning of a document.

Adding a closing bracket might make the fragment syntactically valid, but it cannot recover missing records. If the source is available, fetch or export it again. Use repair only when you understand which data is missing and can verify the repaired result.

Check the request and content type

A wrong endpoint, expired session, or authentication redirect can produce an unexpected body. Confirm the final response URL and status, and check the Content-Type header. A JSON response can still be empty or malformed, so the header alone is not proof.

When reproducing the problem, record a small sample of the actual response rather than a secret-bearing production payload. Test the parser on that sample, then correct the endpoint, server serialization, or client handling that produced it.

Prevent the same failure next time

Keep parsing at a clear boundary. Have the code receiving a response check its status and body, and have the code writing a file complete the serialization before replacing an existing file. For streamed data, use a protocol designed for separate records rather than parsing an unfinished document.

An empty object is not a universal fallback for a failed parse. Silently returning {} can hide an outage and make later code fail in misleading ways. Return the empty value only when it is defined by the contract, and report malformed data with enough context to investigate.

• Validate a captured response in the syntax validator.
• Use the tree viewer once the document parses.
• Add schema validation if a response can be valid JSON but contain the wrong shape.
• Re-download incomplete data before attempting automatic repair.