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.

These are bounded scans, not blind replacements. Each rule skips quoted
strings. Single-quoted bodies are decoded and then serialized again, so escaped
apostrophes, bare double quotes, and // inside URLs are not treated as syntax.

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.

Comments

[Hayrullah Kar]

The rule I'd underline is "stop when it's ambiguous instead of inventing a repair." Most repair libraries fail exactly there: they always return something that parses, so the caller never finds out the payload was wrong in the first place.

One case worth adding to step 4: a single-quoted string that contains an escaped apostrophe. Swapping the outer quotes isn't enough, you also have to unescape the inner \' and re-escape any bare ", otherwise you hand a broken string to the strict parse in step 6. It's the same reason step 1 needs a scanner that tracks whether it's inside a string rather than a regex. A // inside a URL is the classic victim there.

[Tanya]

That escaped-apostrophe case is exactly where a quote swap falls apart. The implementation decodes the single-quoted body, then serializes it with JSON.stringify, so can\'t and bare double quotes are re-escaped correctly. Comment removal also walks quoted spans, which keeps https://... and // inside values untouched. I should make that scanner detail explicit in the article.

[Tomasz]

I have a question about the workflow: if the tool doesn't know whether the JSON is valid until step 6 (strict parse), how does it know which transformations to apply in steps 1-5? Doesn't it risk making repairs that actually break valid structure?

[Tanya]

That would be a real risk if the steps were blind replacements. They aren't selected by the final parse: each rule scans only syntax positions outside quoted strings, and a valid JSON document produces zero changes. The strict parse is the proof after those bounded edits, not the rule selector. Single-quote and bare-key edits are still marked medium confidence, and a remaining parse error stops the handoff. The article should say that more clearly.