Unexpected end of JSON input

The parser ran out of text while it still expected more. Either there was no text at all, or the document stops part-way through, and the message alone does not say which. The first thing to find out is how long the string you passed in really was.

{"id": 7, "name":

Closed unterminated brackets
Filled in a missing value

{"id": 7, "name":null}

An empty body

Parsing an empty string gives exactly this message in Chrome and Node.js, in old and new versions alike. Firefox says JSON.parse: unexpected end of data at line 1 column 1 of the JSON data, Safari says JSON Parse error: Unexpected EOF, and Python reports Expecting value: line 1 column 1 (char 0), which has a page of its own. When the text came from fetch, Chrome adds the method's name in front: Failed to execute 'json' on 'Response': Unexpected end of JSON input.

Empty bodies come from a handful of places:

• A 204 No Content reply, which by definition has no body, read with res.json() anyway. Delete requests and some save endpoints answer this way.
• An error status whose body is empty: many servers send a bare 401, 403 or 500 with nothing after the headers.
• A file that exists but was never written, or was truncated to zero bytes by a crashed write.
• A value read from somewhere that returned an empty string rather than nothing, such as a form field or an environment variable that is set but blank.

Guard against it where the text arrives. Check res.status before reading the body, and treat 204 as "no data" in your own code rather than as a document to parse.

A document cut off part-way

Truncation is the other cause, and here V8's wording depends on exactly where the text stops. The example above ends right after a colon, where a value has to come next, so the parser reports the end of input. Stop the same object after a complete value and current Chrome says it expected a comma or a closing brace; stop it inside a string and the message becomes Unterminated string in JSON. Node.js 18 said "Unexpected end of JSON input" for all three, which is why the phrase is so common in older questions about cut-off responses.

Text gets cut off in ordinary ways:

• A response streamed in chunks and parsed before the last chunk arrived, or a body read by hand from a socket with a fixed-size buffer.
• A proxy or a gateway that caps the response size, or a timeout that closes the connection mid-transfer.
• A log line or a database column that truncates long values, so the JSON stored there was never whole.
• An answer from a language model that hit its token limit before it closed the brackets.

Comparing lengths settles it quickly. Log text.length next to the Content-Length header, or look at the last hundred characters: a document that ends in a comma, a colon or half a word was cut off, and one that ends in a clean } is probably whole.

What Repair can and cannot do

In the validator, Code view underlines the place the text ends. Repair closes what was left open, as the result above shows: it adds the missing brace, and because a key cannot stand without a value it puts null after the colon and says so in its list of fixes. Every change is named, and one undo takes it back.

What Repair cannot do is bring back the part that never arrived. If a list of a thousand orders stops at the four-hundredth, the repaired document is a valid list of four hundred orders, and nothing in it says the rest is missing. That is fine for inspecting a partial response and dangerous for anything that counts or totals the data. When the source can be fetched again, fetching it whole is the real fix. An empty input has nothing to close at all, so Repair reports that it found nothing it could change. The guide to fixing invalid JSON covers the other repairs it makes.