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 millions of JSON examples — but nothing in its decoding loop guarantees the result is well-formed. That gap is why developers building on top of ChatGPT, Claude, Gemini, and open-weight models all 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.

The most common failure is the markdown code fence. Chat-tuned models love to wrap answers in ```json … ``` blocks because that is how code is presented in their training data. The fence is helpful for a human reader and fatal for a parser — 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. Both have to be stripped before the payload can be parsed, which is exactly what this tool does by isolating the text between the first opening bracket and the last closing one.

The second family of problems comes from the model borrowing habits from other languages. It will write single-quoted strings and unquoted object keys because Python, JavaScript object literals, and YAML all allow them — but strict JSON requires double quotes around every string and every key. It will leave a trailing comma after the last element of an array or object, again because most programming languages tolerate it. None of these are bugs in the model so much as bleed-through from the broader corpus it learned from, and all of them are mechanical, reversible mistakes.

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. You see this constantly with long arrays of objects: the model gets ninety percent of the way through a list and the generation budget runs out. The raw text is unrecoverable by a strict parser, but it is very recoverable by a tolerant one: walk the text while tracking whether you are inside a string, close the dangling string, then pop a bracket stack to append the missing ] and } characters in the right order. That is precisely the strategy this repairer uses, and it is why it can salvage output that a naive "find and replace" approach would mangle.

Why a string-aware repair matters

The reason careless JSON fixers corrupt data is that they treat the text as a flat string and blindly replace characters — turning every single quote into a double quote, including the apostrophe inside "it's", or deleting a comma that legitimately lives inside a string value like "Smith, John". A correct repair has to track in-string state: it must know whether the comma, brace, or quote it is looking at is structural punctuation or ordinary text inside a value. This tool reads the input character by character, honours backslash escapes, and only rewrites punctuation that sits outside a string. That distinction is the whole difference between a tool you can trust with real model output and one that quietly damages your data. For deeper structural problems the right long-term fix is constrained decoding or a JSON-schema mode on the model itself — but when you just need to rescue the response sitting in front of you, a tolerant, string-aware repair gets you a clean object you can parse and move on.