LLM JSON Repair

Large language models are trained to predict the next token, not to satisfy a grammar. When you ask one for JSON, it produces something that looks like JSON because it has seen a great deal of JSON, but nothing in plain decoding guarantees the result is well-formed. That gap is why developers building on hosted chat models and open-weight models alike run into the same recurring failures. A single malformed character is enough to make JSON.parse throw, and a thrown parser at the wrong moment can take down a whole pipeline.

A frequent failure is the markdown code fence. Chat-tuned models wrap answers in ```json … ``` blocks because that is how code is presented to a human reader, and the backticks are not valid JSON. Closely related is surrounding prose: "Sure, here's the JSON you asked for:" before the object and "Let me know if you need anything else!" after it. This tool takes the content of the fence when there is one, then looks for the first bracket that can actually open JSON, so a stray "[as requested]" in the prose is not mistaken for the data.

The second family of problems comes from the model borrowing habits from other languages. It writes single-quoted strings the way Python prints a dictionary, unquoted keys the way JavaScript and YAML allow, comments, Python's True and None, and trailing commas that many languages accept. Strict JSON, as RFC 8259 defines it, allows none of these: every string and every key takes double quotes, and values are separated by single commas with nothing after the last one.

Truncation is the failure you cannot retry your way out of

The hardest case is truncation. Every model has a maximum output length, and when a response hits that ceiling it simply stops — often in the middle of a string value, leaving an unterminated quote and a stack of brackets that were never closed. Long arrays of objects are where this bites. A tolerant parser can recover what arrived: it tracks whether it is inside a string, closes the dangling string, drops a key whose value never arrived, and appends the missing ] and } in the right order. Be clear about what that gives you: the last string keeps only the part that arrived, and anything after the cut is gone. The tool marks a cut-off string as a warning for exactly that reason.

Why a string-aware repair matters

Careless JSON fixers corrupt data because they treat the text as a flat string — turning every single quote into a double quote, including the apostrophe inside "it's", or deleting a comma that lives inside a value like "Smith, John". A correct repair has to know whether the comma, brace or quote it is looking at is punctuation or text inside a value. This tool reads the input character by character, honours backslash escapes, and only rewrites punctuation that sits outside a string. For deeper problems the durable fix is a structured-output or JSON-schema mode on the model itself; this is for rescuing the response already in front of you.

What it will not do

It never changes valid JSON. If what you paste already parses, only its whitespace changes: numbers and strings are carried as the text you wrote, so a 20-digit id is not rounded the way JSON.parse followed by JSON.stringify would round it, and duplicate keys are kept and flagged rather than silently collapsed to the last one. It will not guess. An unquoted text value such as {"a": hello world}, a hex number, a missing colon or a key that is neither quoted nor a plain identifier stops the repair with the line and column, because any fix would be an invention. It tells you when it changed a value. NaN, Infinity and undefined have no JSON form and become null; a number written with leading zeros is read as decimal; a cut-off string keeps only its first part. Each of those is listed as a warning, never applied quietly.