waynetools

JSON repair · LLM output fixer

LLM JSON Doctor

Paste the broken JSON an LLM handed you — markdown fences, prose before and after, single quotes, trailing commas, comments, bare keys, Python True/False/None, NaN/Infinity, or output that got cut off mid-string — and this tool repairs it, pretty-prints it, and logs every fix it made. Optional JSON Schema validation. Everything runs in your browser; your JSON is never uploaded.

100% client-side No upload, no tracking Every fix logged & explained
Broken inputwaiting
Repaired output
// Repaired JSON will appear here.
Repairs applied0 fixes
No repairs yet — paste some broken JSON and click Repair JSON.

Optional — validate against a JSON Schema

Paste a JSON Schema and the repaired output is checked against it: missing required properties, type mismatches, and out-of-enum values are reported. Safe type mismatches (a numeric string, a stringy boolean) are coerced and listed. Supports type, properties, required, items, and enum.

no schema run yet
    Heuristic repair, not a guarantee. For the usual LLM breakages it is reliable, but ambiguous or truncated input can be closed off differently than you meant. Read the fix log and eyeball the output before shipping it.

    How it works

    What the doctor fixes

    Ask a language model for JSON and you rarely get clean JSON back. It wraps the payload in a ```json markdown fence, adds a friendly "Sure! Here is the JSON:" preamble, forgets that JSON needs double quotes, leaves a trailing comma from the last array item, drops in a // like this comment, writes Python's True / False / None, or simply runs out of output tokens and stops mid-string. Any one of those makes JSON.parse throw.

    This tool is a small, hand-written lenient JSON parser — no libraries — that reads that messy text the way a forgiving human would, then re-serialises it as strict, pretty-printed JSON. Crucially, it records every change it makes with a plain-English reason, so the repair is auditable rather than a black box. It handles the whole common list: fences, surrounding prose, single quotes, trailing commas, // and /* */ comments, unquoted keys, Python literals, NaN / Infinity, and truncation.

    01

    Paste raw output

    Drop in exactly what the model returned — fence, preamble, truncated tail and all. No need to clean it first.

    02

    Click Repair

    The lenient parser strips the noise, fixes the syntax, and closes anything left open by truncation.

    03

    Read the fix log

    Every repair is listed with what changed and why, so you can trust — or question — each one.

    04

    Validate & copy

    Optionally check it against a JSON Schema, then copy the clean, pretty-printed result.

    Worked examples

    Broken in → clean out

    Fenced + prose + trailing comma
    IN:
    Sure! Here is the JSON you asked for:
    ```json
    {
      "name": "Ada",
      "roles": ["admin", "editor",],
    }
    ```
    
    OUT:
    {
      "name": "Ada",
      "roles": [
        "admin",
        "editor"
      ]
    }
    
    Fixes: removed markdown fence · removed
    prose before JSON · removed 2 trailing commas
    Python literals + truncated tail
    IN:
    {'user': 'kate', 'active': True,
     'score': NaN, 'tags': ['a', 'b',
     'notes': "unterminated and cut o
    
    OUT:
    {
      "user": "kate",
      "active": true,
      "score": null,
      "tags": [ "a", "b", "notes",
                "unterminated and cut o" ]
    }
    
    Fixes: single→double quotes · True→true ·
    NaN→null · closed truncated string + arrays

    Why LLM JSON breaks

    Reading the failure

    The breakages cluster into two families. The first is syntax the model borrowed from the wrong language: single quotes, trailing commas, comments, and True / False / None are all valid in Python or JavaScript source, so a model trained on mountains of both slips them into what it believes is JSON. These are safe, mechanical fixes — there is exactly one correct JSON equivalent for each.

    The second family is truncation, and it is fundamentally different. When a response is cut off because it hit the output token limit, no repair can recover the data that was never generated — it can only close the structures that were left open so the fragment becomes parseable. The right long-term fix lives in your API call, not in a repair tool:

    • Raise the output limit — increase max_tokens (or the provider's equivalent) so the model can finish, or ask for a smaller payload / fewer fields per call.
    • Use a structured-output mode — many providers offer a JSON mode or a response schema / tool-call interface that guarantees valid JSON and removes the fence-and-prose problem entirely.
    • Constrain and instruct — a system instruction like "reply with only JSON, no markdown, no commentary" cuts the prose and fence at the source; this tool is the safety net for when it slips anyway.

    FAQ

    Common questions

    How do I fix broken JSON from an LLM?+

    Paste the raw output into the input box and click Repair. The tool strips the surrounding markdown code fence and any prose before or after the JSON, converts single quotes to double quotes, removes trailing commas and // or /* */ comments, adds quotes around bare object keys, rewrites Python-style True, False and None, replaces NaN and Infinity with null, and closes any brackets or strings the model left open. It then pretty-prints the result and logs exactly what it changed.

    Why is my LLM JSON truncated or cut off?+

    It almost always means the model hit its max output token limit before finishing, so the response stops mid-object, mid-array, or mid-string with no closing brackets. The real fix is to raise the max_tokens setting or ask for a shorter payload, but when you already have the cut-off text this tool recovers what it can: it parses up to the truncation point, closes every open string, array and object in order, and fills a dangling key with null, giving you valid JSON from everything the model did send.

    Can I validate the repaired JSON against a JSON Schema?+

    Yes. Paste a JSON Schema into the optional schema box and the tool checks the repaired JSON against it, reporting missing required properties, type mismatches, and values outside an enum. Where it safely can, it coerces obvious mismatches — a numeric string like "42" to 42, or "true" to the boolean true — and lists each coercion. It supports type, properties, required, items, and enum.

    Does this tool send my JSON to a server?+

    No. There is no network request anywhere in this page. The repair, the pretty-printer, and the schema validator all run in plain JavaScript in your browser tab. You can open the page, turn off your Wi-Fi, and it keeps working — nothing you paste is ever uploaded, logged, or stored, which matters when the JSON holds API responses, customer data, or anything you would not paste into a random web form.

    Why does asking a model for JSON produce Python True, False or None?+

    Models are trained on huge amounts of Python and JavaScript, and Python's literals are True, False and None with capital letters, plus NaN and Infinity. JSON requires lowercase true, false and null and cannot write NaN or Infinity at all, so a model in Python mode emits tokens that look right but are invalid JSON. This tool rewrites those to the JSON equivalents, replacing NaN and Infinity with null.

    Is the repair guaranteed to be correct?+

    No — it is a best-effort heuristic, not a guarantee. For the common breakages LLMs produce it is reliable, but ambiguous input can be read more than one way: a string containing an unescaped quote, or a value truncated in the middle, may be closed off differently than you intended. Always read the fix log and eyeball the repaired output before using it in production, especially when the tool reports it closed a truncated structure or inserted a missing comma.