JSON Repair

The single largest source of malformed JSON today is a language model. You ask for JSON, you get Sure! Here is the JSON you requested: followed by a markdown code fence, single-quoted keys, a trailing comma, a stray NaN where a number should be, and — if the response hit its token limit — no closing brace at all. Standard formatters simply refuse the whole thing, which is technically correct and completely useless when you have a hundred of these to process.

This tool is built for exactly that input. It strips the fence and any leading prose first, then runs the jsonrepair library over what is left to fix the structural damage, then parses the result with native JSON.parse so you know the output is genuinely valid rather than merely improved. It tells you what it changed, so you can decide whether a repair was a fix or a guess.

What it fixes

The repair runs in two stages. First, the wrapper is removed:

• A surrounding markdown code fence — ```json, ```json5, ```jsonc or a bare ``` — is stripped.
• Leading prose before the first { or [ is discarded, which handles the conversational preamble that models add even when told not to.

Then the jsonrepair library repairs the JSON itself:

• Trailing commas before } or ] are removed.
• Single-quoted strings and keys are converted to double quotes, along with smart quotes pasted in from elsewhere.
• Unquoted keys — {name: "x"} — get their quotes.
• Comments, both // and /* */, are stripped.
• Non-JSON literals are converted: Python-style True and False become true and false, None becomes null, and NaN and Infinity — which have no JSON representation at all — are preserved as the quoted strings "NaN" and "Infinity" rather than being silently dropped.
• Truncated documents are closed: unterminated strings, objects and arrays get the delimiters they are missing.
• Missing commas between adjacent objects or array items are inserted, and concatenated JSON fragments are joined into an array.

Repairing truncated LLM output

Truncation is the failure mode worth thinking hardest about. When a model runs out of output tokens mid-object, the repair closes every open string, object and array so the document parses — but it cannot invent the values that were never generated. You get syntactically valid JSON that is semantically incomplete: the last record may be missing half its fields.

That is usually the right trade. A parseable document with a short final record can be inspected, logged and partially salvaged; an unparseable one cannot. But treat a truncation repair as a signal that your generation ran out of room, not as a fix. The durable answers are raising the output token limit, requesting fewer records per call, or using structured-output or function-calling modes where the provider constrains generation to a schema and cannot emit a fence or a preamble in the first place.

The same applies to a model that stopped mid-sentence inside a string value. The string will be closed at the truncation point, and the text simply ends there.

When repair is the wrong tool

Repair is a rescue operation, not a workflow. If the same source produces broken JSON every time, fix the source: it is cheaper and it does not silently reshape your data.

There is also a class of input that no repairer should touch. If the fault is a genuine ambiguity — a value that could plausibly be a string or a number, a structure where a missing comma could be inserted in two different places — any automatic fix is a guess, and a guess that produces valid JSON is more dangerous than a loud failure, because nothing downstream will question it. Read the notes, and eyeball the output against the input when the document matters.

Input that is too badly damaged to yield valid JSON at all is rejected with an explicit message rather than returned half-repaired.