{"ok": true,}Trailing commas
Removes a comma immediately before } or ]. A comma stranded at the end of truncated input is marked as an assumption because a missing value may have followed it.
Interactive repair workspace
Paste broken JSON and review the proposed fix
Repair happens after a short typing pause. A successful result has passed strict, lossless JSON validation, but low-confidence repairs can still represent the wrong intent. Read the assumptions and diff before using repaired data in production.
Loading the local JSON repair tool…
JavaScript is required for interactive repair, change tracking, and diff generation.
JavaScript is required for interactive repair, change tracking, and diff generation.
Supported repairs
What this JSON repair tool fixes
LiveParse targets a deliberately limited set of mistakes that appear frequently when JSON is copied from code, generated by a language model, or cut off during streaming. It does not run the input as JavaScript and it does not silently invent complex object structures.
{'name': 'Ada'}Single quotes
Converts single-quoted keys and strings into strict JSON double quotes. Internal apostrophes and unusual escapes trigger an assumption so that human review is not skipped.
// noteLine and block comments
Removes // and /* … */ comments only when they occur outside strings. Text such as https:// inside a quoted URL remains untouched.
True · False · NonePython literals
Changes Python booleans and null-like values to JSON true, false, and null. Matching words inside strings are preserved as normal text.
```json … ```Fences and surrounding prose
Extracts a JSON-looking value from a Markdown code fence or an explanatory LLM response. Because selecting a payload from prose involves intent, the extraction is disclosed as an assumption.
{"items":[1,2Truncated output
Closes a cut-off quoted string, array, or object when the remaining structure is unambiguous enough to validate. Missing property values may become null, always with low confidence.
Repair you can audit
How LiveParse repairs JSON safely
The result is more than a green “valid” badge. Four separate checks help you decide whether the repaired text is appropriate for your API, log pipeline, test fixture, or configuration file.
Edits stay at the token level
The repair engine rewrites text directly. It never calls eval(), Function(), or a JavaScript expression parser, so pasted code cannot execute as part of repair.
Numbers are not coerced
The repaired text is validated with an AST parser that retains each raw number token. Values such as 9007199254740993 and 1e400 are not routed through JavaScript number.
Repeated keys remain present
Object members stay ordered in the lossless syntax tree. If a key appears twice, both occurrences remain in the repaired output and a warning identifies the duplicate instead of silently keeping only the last value.
Every change has an audit trail
Direct transformations and assumptions are labeled separately. Source location, a compact before-and-after value, confidence score, and line diff make a risky guess easy to spot.
Confidence is not correctness
What high, medium, and low confidence mean
A valid repair can still be semantically wrong
Syntax repair can prove that the output follows the JSON grammar. It cannot know whether a missing amount should be null or zero, whether a truncated array omitted more records, or which duplicate key your application intended. Confidence describes the kind of edits made; it is not a probability that the business data is correct.
Keep the original input, compare the complete diff, and validate the result against your application rules or JSON Schema before replacing production data.
- High confidenceOnly direct syntax conversions, such as a trailing comma or a complete Python literal, were required.
- Medium confidenceThe tool made a contextual choice, such as extracting a likely JSON value from surrounding text.
- Low confidenceThe source was truncated or required an invented delimiter or placeholder value. Manual review is essential.
Know when to stop
What the repair tool intentionally does not guess
Automatic repair stops when the remaining syntax has several plausible meanings. Examples include a missing comma between two complete values, an unquoted expression, mismatched closing brackets, or prose with no identifiable JSON value. Stopping is safer than returning convincing but fabricated data.
Business meaning and schemas
LiveParse does not infer required fields, choose a currency, correct an ID, enforce an enum, or decide which duplicate property wins. Use domain checks or a schema validator after repair.
JavaScript and template expressions
Functions, arithmetic, environment references, template literals, and executable expressions are rejected. This protects the local-only workflow and avoids turning data repair into code execution.
Common questions
JSON Repair FAQ
Does LiveParse upload the JSON I paste?
No. Repair, lossless validation, warnings, and diff generation run in the current browser tab. The tool does not submit the JSON input to a LiveParse server. See the privacy page for information about loading the website itself and any third-party services.
Will a 64-bit integer change during repair?
The repair pipeline keeps numeric tokens as text and validates them in a lossless AST. It does not use JSON.parse() followed by JSON.stringify(). Unsafe integers, exponent overflow, and number spellings that JavaScript would rewrite are warned about while the original numeric lexeme remains intact.
What happens to duplicate object keys?
Both members remain in their original order, and the lossless validator reports a duplicate-key warning. Different JSON consumers handle duplicate names differently, so resolve the duplication deliberately before sending the data to another system.
Can I repair JSONL or NDJSON here?
This page repairs one JSON value. Use the dedicated JSONL Parser for newline-delimited records, line-specific errors, filtering, table inspection, and CSV export.
Should repaired LLM JSON be trusted automatically?
No. A model response may be syntactically repairable while still containing invented fields, omitted records, or incorrect values. Use the change list to understand syntax edits, then verify the actual data against the prompt, source material, and expected schema.