JSON

LLM JSON Validator

Clean up JSON from an LLM response -- extracts it from markdown fences or surrounding prose (even with multiple code blocks), fixes smart quotes, Python literals, comments, single-quoted strings, unquoted keys, trailing commas, and auto-closes JSON truncated by a token limit -- with a step-by-step repair report.

What this tool does

Paste the raw text an LLM replied with — not just the JSON itself, the whole response, fence and commentary included — and get back clean, valid JSON. A plain JSON validator expects well-formed input; this is built for a response that usually is not.

Getting the JSON out of the response first

A model rarely replies with pure JSON — it is normally wrapped in a ```json fence, or embedded in a sentence like "Sure, here's the data you asked for: ...". The actual JSON value is located automatically, either by finding the fenced block or, with no fence at all, by scanning for the first {/[ and matching brackets correctly (respecting string contents, so a stray bracket inside a quoted value does not confuse it). When a response contains more than one code block, a selector picks which one to validate instead of assuming there is only one.

The specific ways LLM output breaks JSON

Several fixes target patterns that come specifically from how models generate text, applied in order, only when needed:

Smart quotes — typographic " "/' ' instead of straight quotes, common when a model's output passes through something that "prettifies" punctuation.
Python literals — True, False, None, NaN, Infinity, from a model slipping into Python dict syntax instead of JSON.
Comments, single-quoted strings, and unquoted keys — all valid in the kind of code a model has seen far more of in training than strict JSON.
Trailing commas after the last item in an object or array.

When the response got cut off

A reply that hit a token limit mid-generation leaves JSON truncated — an object or array left open, a string never closed. Auto-close walks the open brackets and any unterminated string and closes them in the right order, turning a cut-off response into something that parses, rather than a fragment that has to be discarded entirely.

Seeing exactly what was fixed

Every repair step that actually ran is listed in order — not just "fixed it" — and if the result still cannot be parsed as valid JSON, the best-effort repaired text is shown anyway, ready for the remaining fix to be made by hand instead of starting over from the original response.

Privacy

Extraction and repair both happen in your browser. Nothing you paste, drop, or load from a file is sent to a server.

FAQ

Frequently asked questions

Is my data uploaded anywhere?

No. Extraction and repair both run locally in the browser — nothing is sent to a server.

Why does an LLM response need special handling instead of a regular JSON validator?

A regular validator expects well-formed JSON with nothing else around it. An LLM response is usually wrapped in a markdown code fence, mixed with commentary, and prone to specific patterns like Python literals, smart quotes, or a truncated ending from a token limit — all of which a strict validator would just reject outright rather than work around.

What happens if the response contains more than one code block?

A selector lists every code block found and lets one be chosen to validate, rather than assuming the first block is always the intended one.

Can something usable be recovered from a response that got cut off?

Often, yes — auto-close tracks which brackets and strings were left open and closes them in the correct order, turning a truncated reply into JSON that actually parses, instead of an unusable fragment.

What happens if it still cannot produce valid JSON?

The best-effort repaired text is shown regardless, along with the specific parse error, so whatever remains can be fixed by hand starting from a partially cleaned version rather than the original raw response.

Does it show exactly what was changed to make the JSON valid?

Yes — every repair step that actually applied is listed in the order it ran, so it is clear exactly what was different about the model's original output, not only that the final result happens to be valid.