How to repair invalid JSON without changing its meaning

Start by separating syntax from data quality

JSON can fail for a small mechanical reason even when the intended data is obvious to a person. Common examples include single-quoted strings, unquoted property names, trailing commas, comments, or a missing separator. A parser rejects the whole document because JSON has a deliberately narrow grammar. Repairing that grammar is different from deciding whether the fields, values, and relationships are correct for an application.

Preserve the original before changing anything. The original is the only reliable record of what was received, and it lets you distinguish a repair from an accidental rewrite. If the input came from an API, log, or configuration system, also record its source and encoding. A copied fragment may be incomplete even after every visible punctuation error has been fixed.

Repair the least ambiguous errors first

Begin with changes that have one clear interpretation: remove a trailing comma, replace JavaScript-style single quotes with JSON double quotes, or quote a plain property name. Then parse again. Small repair steps make it easier to see which change made the document valid and reduce the chance of silently inventing data.

Stop when information is missing rather than merely malformed. A truncated string, absent value, or unbalanced nested object can have several plausible completions. A tool may suggest a parseable result, but only a person who understands the producing system can decide which missing content was intended.

• Keep numbers as numbers unless the source clearly intended an identifier string.
• Treat dates as strings unless an application schema says otherwise.
• Do not delete unknown properties simply to satisfy a consumer.
• Never add credentials or defaults that were not present in the source.

Review structure and meaning after parsing

Successful parsing proves that the output follows JSON syntax. It does not prove that required properties exist, values use the correct types, identifiers are unique, or dates fall within an allowed range. Compare the repaired result with the original and inspect every location where a character was inserted, removed, or replaced.

When a schema is available, validate against it after repair. When there is no schema, compare the result with a known-good example from the same system. JSON Diff is useful for this second step because it ignores formatting and shows changes by property path, but array reordering and schema rules still require human interpretation.

Handle production data defensively

Prefer synthetic or redacted examples when debugging. A local browser tool avoids sending text to an application server, but clipboard managers, extensions, screen sharing, crash reports, and other software on the device may still observe sensitive values. Rotate any token or password that was pasted into an environment you do not fully trust.

Before deploying a repaired configuration, run the application's own tests and load it in a non-production environment. A parseable document can still change feature flags, permissions, endpoints, or numeric behavior. Keep the repair as a reviewable change rather than overwriting the only copy of the input.