JSON Repair — Fix LLM-Mangled JSON
Paste broken JSON (or paste an LLM response that contains JSON mixed with prose — the tool extracts the JSON block). The right panel shows the repaired output and a change log lists every fix applied. Best-effort: for truly mangled output (truncated mid-token, mixed encodings), some recoveries fail.
Change log
How to repair JSON
- Paste broken JSON (or paste an LLM response that contains JSON mixed with prose — the tool extracts the JSON block).
- The right panel shows the repaired output. A change log below lists every fix applied ("removed trailing comma on line 12", "wrapped unquoted key
namein quotes"). - If the repair confidence is low, the banner says Best-effort repair — review before using.
- Copy the result, or Format to jump straight to json-formatter with the cleaned output.
What it fixes
- Trailing commas after the last item in arrays / objects, plus stray and doubled commas.
- Single quotes around strings and keys → double quotes, with any
"inside them escaped. - Unquoted keys (
{name: 1}) → quoted keys. Bare words in value position are quoted too. - Smart quotes (curly
“ ”from word processors) where they are being used as the quote marks. - Comments —
//,/* */and#. - Other languages' literals —
None,nil,undefined,NULL,True/False, andNaN/Infinity(which becomenull, since JSON has no such number). - Number spellings JSON does not allow —
0xff,+3,.5,5.,007. - Raw line breaks, tabs and control characters inside strings — escaped rather than left to break the parse. This is the usual damage when JSON is copied out of a log.
- Unclosed brackets and an unterminated string at the end — closed, which is what a truncated response needs.
- BOM (byte order mark) at the start of a file — stripped.
- Prose around JSON ("here's the JSON:
{...}") — the JSON block is extracted.
What it will not do: touch the inside of a string
Every fix above is applied by a single left-to-right scan that always knows whether it is inside a string. That distinction is the whole difference between a repair tool and a corruption tool.
A pattern-replacement approach — strip // to end of line, delete a comma before
], straighten curly quotes — also matches inside string values, where
those characters are data. {"a": "x // y"} loses everything from the slashes on.
{"a": "it's fine"} has its apostrophes read as quote marks.
{"note": "1, ]"} quietly becomes {"note": "1]"} — which still
parses, so nothing reports a problem and your data is simply different now. That last one is
the reason this was rewritten: a repair that fails loudly is fine, and one that succeeds
wrongly is not.
Valid JSON therefore comes back unchanged, with an empty change log, whatever its strings contain.
FAQ
Why is this a "best effort"?
Some breakage is genuinely ambiguous — a number written "1,234" could be one number or two, and nothing can tell which. A truncated document is closed off at the end, which recovers the part that arrived but cannot invent the part that did not. The change log lists every fix applied; if the result still doesn't parse, the remainder needs a person.
Will it handle JSON5?
Yes. Comments, trailing commas, unquoted keys, single quotes, hex numbers, leading +, and .5 / 5. numbers are all handled. JSON5's \-continued strings and its Infinity are converted rather than preserved — Infinity becomes null, because JSON has no way to write it.
Why did my LLM output extract incorrectly?
If your LLM put multiple JSON snippets in one response (e.g. two code fences), the tool grabs the first object/array span only. Split the response by hand before pasting.
Will it work offline?
Yes — after the page loads. The repair runs locally on your browser.