Unterminated string in JSON

A string opened with a double quote and the text ended before the closing one. Since a JSON string cannot contain a raw line break, a missing quote cannot be hiding somewhere later in the document: the parser reached the very end of the input while it was still inside the string. That almost always means the text was cut off.

{"id": 7, "name": "Ad

Closed unterminated brackets
Closed unterminated strings

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

Where each runtime points

The numbers disagree, and the difference is worth knowing. Chrome, Node.js and Firefox point at the end of the text, column 22, where they gave up waiting for the quote. Python points back at column 19, the quote that opened the string, and says so: starting at. On a long document Python's position is the more useful one, since it takes you straight to the value that never closed. Safari names no position at all. Node.js 18 did not treat this case separately and reported an unexpected end of JSON input.

Why the text stopped

Look at how much text you actually have before you look for a typo. A string that runs to the end of the input is a truncation until proven otherwise, and the usual suspects are:

• a response read before it finished arriving, or cut short by a timeout or a size limit somewhere between the server and your code;
• a value stored in a column or a log field with a maximum length, where the long description at the end of the object is exactly what got clipped;
• a model's answer that ran out of tokens in the middle of a sentence inside a string value;
• a copy from a terminal or a web page that stopped at the edge of the visible text.

Two related mistakes produce different messages, so they are easy to tell apart. A tab or a line break inside a string is reported as a bad control character. A quote missing in the middle of a document usually makes the parser read on to the next quote and then fail on whatever follows, which reads as Expected ',' or '}' after property value.

Streaming makes this error easy to cause by accident. Code that parses each chunk of a response as it arrives, instead of waiting for the whole body, will meet a string split across two chunks sooner or later. Collect the chunks and parse once the stream has ended, or use a parser built for partial input. With a language model, a larger token limit or a request for a smaller object stops the answer from being cut off in the first place.

A cut that happens to fall between two values rather than inside a string produces one of the other messages on this site instead, so the same truncated response can fail with different words on different days, depending only on where the last byte landed.

Fixing it

When the source can be read again, read it again, whole: nothing after the cut can be recovered from what you have. Compare the length of the text with the Content-Length header or with the size of the file on disk to confirm the cut before changing any code.

When a partial document is all there is, paste it into the JSON Validator. Code view underlines the unfinished string, and Repair closes it and every bracket still open around it, as the result above shows. The string keeps the characters that arrived, so "Ad" stays "Ad" rather than being completed into a name nobody wrote. The document then parses and is safe to browse, but treat what it says as incomplete: the last value is shorter than it should be, and any keys that came after it are missing entirely. The guide to fixing invalid JSON shows the other things Repair can put right.