How to Repair Almost-JSON Without Guessing

AI responses, logs, and configuration snippets often look like JSON without
being valid JSON.

Typical examples contain:

• Markdown fences around the payload.
• Comments.
• Single-quoted strings.
• Trailing commas.
• Bare object keys.
• Python literals such as True, False, and None.

The tempting fix is a chain of regular expressions. That works until a string
contains punctuation that looks like syntax. A safer repair workflow is narrow,
explainable, and followed by a real parse.

Keep the original

Do not edit the only copy. Preserve the raw response or log fragment before
changing anything.

If the source includes prose or Markdown, first isolate the candidate JSON
block. A repair tool should not guess which paragraph was intended to be data.

For example:

Here is the result:

```json
{
  status: 'ok',
  retry: False,
  items: [1, 2, 3,],
}
```

The data block is repairable. The surrounding sentence is not part of the
document.

Apply known transformations

Use a deterministic sequence and record every change:

1. Remove supported comments without touching comment-like text inside strings.
2. Normalize True, False, and None.
3. Quote bare object keys.
4. Replace single quotes only when the structure is unambiguous.
5. Remove trailing commas.
6. Parse the result with a strict JSON parser.

The example can become:

{
  "status": "ok",
  "retry": false,
  "items": [1, 2, 3]
}

If two interpretations are possible, stop. A visible parse error is safer than
a confident but invented repair.

Validate meaning after syntax

Valid JSON can still be wrong.

An AI response may omit a field, turn a number into a string, or stop halfway
through an array. A log fragment may contain only one nested object from a
larger payload.

After the strict parse:

• Compare the result with a known-good example.
• Check important value types.
• Use a JSON Schema for API payloads.
• Use a tree diff for configuration changes.
• Keep the repair report with the result during review.

Syntax repair answers "can this be parsed?" It does not answer "is this the
right data?"

Keep production payloads local

Broken JSON often comes from places that contain customer data, internal IDs,
or credentials. Sending it to a formatter creates another copy outside the
system you are debugging.

MonoTools JSON Repair runs in the current browser tab and shows the repair
rules it applied:

https://monoware.app/guides/repair-broken-json-safely?utm_source=devto&utm_medium=content&utm_campaign=json_repair_guide

The guide also links the next checks: strict formatting, JSON Tree Diff, and
JSON Schema.

Disclosure: MonoTools is my project. The repair tool intentionally leaves
ambiguous input unresolved instead of pretending every invalid document has one
obvious answer.