Paste the broken JSON a language model just handed you. Get valid JSON back, a named diagnosis for every repair, and the prompt or API change that prevents each failure at the source.
Load the sample for a deliberately awful model response, or paste your own. Every repair this tool makes is reported as a named finding with a location, an explanation, and the fix that stops it recurring.
Repair is heuristic. Every fix below is an inference about what the model meant, not a derivation. Single quotes almost certainly meant a string, but an unquoted bare word might have meant an enum, and a number with leading zeros might have meant an identifier. When intent is ambiguous this tool picks the reading that loses the least data and says so in the finding, so you can disagree with it.
A truncation repair cannot invent the missing content. When the output stops mid-value, all this tool can do is close the containers that were still open so the result parses. The data after the cut is gone. Parseable JSON with silently missing fields is more dangerous than a clean failure, so a truncation finding is flagged as fatal even though the output parses.
Structured output modes are strictly better than repairing after the fact. If you can constrain the response with a tool or function schema, or a JSON-schema output format, the serializer writes the JSON and none of these failure modes can occur. Post-hoc repair is for output you do not control, or a pipeline you have not fixed yet. It is a triage tool, not an architecture.
Nothing here validates against your schema. A repaired document can parse perfectly and still have the wrong shape, wrong field names, or hallucinated values. Verification below means "JSON.parse accepted it", nothing more.
For everyday JSON work - formatting, tree browsing, JSONPath queries, diffing, converting - use json-workbench, which includes a tolerant-parse mode for ordinary malformed JSON; this tool is narrower on purpose, covering only LLM-specific failure modes and the prompt-level fix for each one.