How to repair malformed JSON instead of starting over

You get a JSON file and it won’t parse. Your first instinct is to go find the source and re-export. Sometimes that’s right. But a surprising amount of broken JSON is broken in mechanical ways — mistakes a tool can fix in a second, saving you the trip back to the data’s origin. The skill is knowing which category you’re looking at.

What repair tools can fix

Most invalid JSON fails for a small set of mechanical reasons, and these are all repairable:

• Trailing commas — {"a": 1,} → {"a": 1}.
• Single quotes instead of double — {'a': 'b'} → {"a": "b"}.
• Unquoted keys — {a: 1} → {"a": 1} (common in config files and logs).
• JavaScript comments — // and /* */ lines that snuck in (JSONC-style files).
• Missing braces or brackets — a truncated array or object with one closing bracket short.
• NaN / Infinity — invalid JSON numbers, repairable to null (best-effort).
• Control characters — raw newlines or tabs inside strings that need to be \n / \t escapes.

Each of these is a mechanical transform: the parser knows the structure, the string is unambiguous, and the repair is deterministic.

What repair tools can’t fix

Repair is not magic. It can’t invent information that was destroyed:

• Genuinely truncated data. If the file was cut mid-string — "nam with the rest gone — a repair tool can close the brace but the value is lost. You get valid JSON that’s missing data. Dangerous, because it parses.
• Encoding corruption. Replaced or mangled bytes can’t be recovered from the JSON itself.
• Semantic errors. Valid JSON with the wrong values, duplicate keys that change meaning, or a schema mismatch — repair tools don’t touch these, and they shouldn’t.

That last point is the important one. A repair tool’s output parses, but parsing is not correctness. If the fix made up structure to close a brace, you’ve got valid-but-wrong data.

The safe workflow

1. Validate first. Confirm it’s actually broken and see where.
2. Repair the mechanical issues.
3. Validate again. The output must parse cleanly.
4. Diff the result against the original — eyeball what changed. If the repair deleted or invented content, that’s your signal to go back to the source.

That last step is why you should never blind-accept a repair. A good tool makes the original and the fixed version easy to compare, so you can confirm it only did mechanical cleanup.

When to re-export instead

Skip the repair entirely and go back to the source when:

• The data is truncated and the missing part matters (re-export the full file).
• The file is huge and the error count is high enough that you can’t trust spot-checks.
• The JSON is generated by a buggy exporter — repairing the output every time hides the real bug. Fix the exporter.

How to do it

A JSON repair tool that fixes the mechanical list above, shows you a diff, and flags what it had to guess at will turn a five-minute debugging session into a two-second paste. Run it client-side and even the payload stays private. But remember the order of operations: validate, repair, validate, diff — repair is a tool, not a verdict.