JSON Repair Tool
Turn malformed JSON-like text into strict JSON locally, with selectable repair modes and clear warnings for inferred changes and data risks.{{ summaryTitle }}
{{ summaryLine }}
{{ computation.values.repaired_text }}
| Stage | Status | Count | Evidence | Copy |
|---|---|---|---|---|
| {{ row.stage }} | {{ row.status }} | {{ row.count }} | {{ row.evidence }} |
| Signal | Value | Review meaning | Copy |
|---|---|---|---|
| {{ row.signal }} | {{ row.value }} | {{ row.meaning }} |
The chart renderer is unavailable. The same intervention counts remain available in the repair ledger and CSV export.
JSON succeeds by being strict. Object names use double quotes, members and array items need commas, strings allow a defined set of escapes, and the only literal values are true, false, and null. A payload that looks understandable to a person can still fail at the first parser.
Broken JSON often inherits syntax from a nearby format. Configuration examples contain comments, JavaScript objects use unquoted keys and single-quoted strings, Python output includes True or None, and copied model responses may wrap the value in Markdown or stop before the final brace. The source context matters because each repair rule makes an assumption about what the author intended.
- Syntax repair
- Changes text until one strict JSON value can be parsed.
- Semantic review
- Checks whether inferred changes still express the intended data.
- Schema validation
- Checks the parsed value against the fields, types, and rules expected by its destination.
These are separate jobs. Appending a missing brace can make a truncated object parse without restoring omitted fields. Replacing undefined with null produces legal JSON but changes the distinction between an absent value and an explicit empty value. Sorted output can make diffs stable while changing object-member order.
Syntactic success also leaves two important interoperability risks. Duplicate object names are handled differently by parsers; many keep only the last value. Integers beyond the exact range of an IEEE 754 binary64 number may lose digits when parsed into an ordinary browser number.
Treat repaired JSON as a review candidate. Confirm the root type, key and item counts, nesting depth, duplicate-name warnings, and large-integer warnings before it reaches an API, configuration file, or data import.
How to Use This Tool:
Start with the least permissive mode that matches the source, then review every inferred change.
- Paste one document into Broken JSON source. Source text is processed locally and must not exceed 2 MiB.
- Choose Auto detect when visible syntax makes the source family clear, or pin Conservative syntax, JSONC cleanup, JavaScript object, LLM or log paste, or Common fixes when you know the source.
- Choose Readable JSON, Compact JSON, or Sorted JSON. Sorted output recursively orders object keys for local diffs; it is not a signing or standards-based canonicalization scheme.
- Open the advanced settings only for a known defect. Smart-quote and invalid-escape repair, comma insertion, and closer completion are opt-in because each can change ambiguous text.
- Read Repair ledger from extraction through final strict parse. If parsing still fails, correct the text near the reported line and column or choose a mode that matches the source.
- Compare Repaired JSON with Structure audit. Copy the result only after root type, duplicate names, unsafe integers, and the applied repair count make sense.
Interpreting Results:
Valid JSON means the final text parsed as one JSON value. It does not prove that the payload is complete, conforms to a schema, preserves the author's intent, or is safe for a receiving system.
- A high Repair change count deserves closer comparison with the source, especially after comma or closer insertion.
- Duplicate keys mean the browser parse kept a later value and may have hidden an earlier one.
- Precision risk means at least one parsed integer was outside the exact safe-integer range.
- Sorted JSON changes key order recursively. Compare values rather than assuming the text is byte-for-byte equivalent.
Technical Details:
The repair path is deterministic and bounded. It first isolates a likely payload, attempts a strict parse, applies only the stages allowed by the resolved mode and enabled options, then parses again. Output is emitted only from the parsed value, so a successful result is strict JSON rather than a best-effort string.
Transformation Core
The stages run in a fixed order because one change can expose the next recognizable boundary.
- Remove a byte-order mark, then use a Markdown code fence or the first JSON-looking object or array when the selected mode permits wrapper extraction.
- Attempt an initial strict parse and stop changing the text when it already succeeds.
- Optionally normalize smart quotes, then remove comments and trailing commas.
- Convert closed single-quoted strings, quote JavaScript-style bare keys, and map
True,False,None,undefined,NaN, andInfinityto strict JSON literals. - Optionally repair invalid string escapes, insert commas at recognizable adjacent-value boundaries, and append recoverable closing quotes, brackets, or braces.
- Run the final strict parse, format the parsed value, and calculate the structure and warning evidence.
Rule Core
| Mode | Automatic repairs | Optional repairs it can honor |
|---|---|---|
| Conservative syntax | Trailing commas | None |
| JSONC cleanup | Comments and trailing commas | Smart quotes and invalid escapes |
| Common fixes | Comments, trailing commas, single quotes, bare keys, and loose literals | Smart quotes, invalid escapes, and missing commas |
| JavaScript object | Common-fix stages | Smart quotes, invalid escapes, missing commas, and truncated closers |
| LLM or log paste | Wrapper extraction and JavaScript-object stages | Smart quotes, invalid escapes, missing commas, and truncated closers |
Auto detection resolves LLM or log mode for fenced or prose-wrapped content, JSONC mode for comments, JavaScript-object mode for bare keys, single quotes, or loose literals, conservative mode for trailing commas alone, and common fixes otherwise. A pinned mode bypasses that selection.
Strict output and audits
Readable output uses 0 to 8 spaces of indentation. Compact output removes insignificant whitespace. Sorted output recursively orders object keys with a case-insensitive locale comparison while leaving array order unchanged.
The audit walks every parsed value to count nodes, objects, arrays, keys, scalar types, maximum depth, largest containers, and unsafe integers. Duplicate names are detected from the pre-parse text because a normal parse can no longer recover overwritten members.
Privacy Notes:
The source stays in the current browser tab and is excluded from the share URL. No source document is uploaded or stored by the repair process.
Copied and downloaded output can still contain passwords, tokens, personal data, or other secrets from the input. Review and handle those artifacts according to the destination's data policy.
Worked Examples:
Configuration comment and trailing comma
For {"enabled": true, // rollout flag
}, JSONC cleanup removes the comment and trailing comma before the final parse. The ledger should show both changes. The result is syntactically clear because neither stage invents a missing value.
Truncated model output
A fenced array ends after its third object without the closing bracket. LLM or log mode can extract the fenced block, but closer completion runs only when explicitly enabled. If appending ] produces valid JSON, confirm that the author intended exactly three items before reuse.
References:
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, RFC Editor, December 2017.
- ECMA-404: The JSON Data Interchange Syntax, Ecma International, second edition, December 2017.
- RFC 7493: The I-JSON Message Format, RFC Editor, March 2015.
- JSON with Comments specification, JSONC.org.