JSON Repair

A validator only tells you something is wrong and where. A repair tool actually fixes the document and returns valid JSON. The errors repair tools handle include: trailing commas after the last array element or object property (valid in JavaScript, invalid in JSON), single-quoted strings, unquoted object keys, Python-style True/False/None instead of JSON true/false/null, JavaScript-style // and /* */ comments, and markdown code fences (```json...```). These are the most frequent mistakes when hand-editing JSON or copying from JavaScript source code.

LLMs generate text token by token with no awareness of JSON grammar. The most common problems are: truncation at the token limit, leaving open brackets or unterminated strings; markdown fences wrapping the JSON; explanatory prose prepended or appended to the JSON object; and occasional hallucinated syntax like trailing commas or Python boolean literals. Streaming LLM responses are inherently incomplete JSON at any moment until the stream finishes. JSON repair tools are now a standard part of LLM output post-processing pipelines.

Yes, in ambiguous cases. If a string is missing its closing quote, the repair tool must guess where the string ends — it typically reads until the next structural character (}, ], ,). If the original content contained those characters, data can be silently mangled. Repair tools are heuristic, not telepathic. Always validate the repaired output against your expected schema. For critical data pipelines, treat repair as a recovery step and log the original broken input so you can audit what was changed.

JSON linting validates syntax and reports errors with line and column numbers. JSON formatting (prettifying or minifying) changes whitespace and indentation but requires the input to already be valid JSON. JSON repair attempts to make an invalid document valid by correcting or inferring the intended syntax. The operations are sequential: repair first to get valid JSON, then lint to confirm it is valid, then format for readability. A formatter will fail on invalid input; a repair tool is specifically designed for invalid input.

Modern repair libraries maintain a streaming mode where they process input incrementally. When a truncated chunk arrives — for example {"name": "Alice", "scores": [10, 2 — the library closes all open structures in the correct order (most recently opened first, following LIFO semantics), producing {"name": "Alice", "scores": [10, 2]}. This enables live UI rendering of partial LLM JSON output without waiting for the full response to complete.