JSON Repair and Auto-Fix

Turn pseudo-JSON copied out of source code or logs — comments, single quotes, trailing commas, unquoted keys — into standard JSON that other languages will accept.

The "JSON" people copy out of JavaScript source, log lines or chat messages is frequently not JSON: keys without quotes, strings in single quotes, a comma after the last member, embedded comments, and occasionally undefined or NaN. All of that runs fine in JavaScript and is rejected outright by a JSON library in Java, Go or Python. Fixing it by hand is slow and easy to get wrong in exactly the spots that matter.

Repair executes locally in the browser. Pasted internal payloads and configuration files never leave the machine, and there is no backend call involved, so it works with the network off. The editor remains an ordinary editable document afterwards: you can hand-tune the result and then continue with formatting, minification or key sorting, which means the repair step does not lock you into a fixed pipeline.

What it fixes, and what it cannot

Five classes of problems are covered: // line comments and /* */ block comments; trailing commas immediately before } or ]; strings wrapped in single quotes; bare keys without quotes, including keys that begin with a digit; and undefined or NaN appearing in value position. What it does not handle is structural damage — a missing comma between two members, unbalanced brackets, an unterminated string, content truncated during copy. Text like that still fails to parse after the repair rules are applied, and the tool says so explicitly rather than returning a plausible-looking but incomplete result.

Why the repair does not corrupt string contents

A naive implementation would run string replacement across the whole document, which walks straight into trouble: in a URL such as https://host//path it would treat everything after // as a comment and delete it, and a value containing the literal text ", total: 5" would be mangled. This tool instead splits the input into string segments and code segments using the quote characters, normalizes each string segment into valid double-quoted form, and applies the comment, trailing-comma and bare-key rules only to code segments. URLs, regex fragments, and text values containing commas, colons or braces therefore survive the repair intact.

What you get back, and what to check yourself

On success the output is re-emitted with two-space indentation — a valid, clearly structured JSON document that the other tools can consume directly. Two things need your own judgement. First, the comments being discarded often carried field meanings, units or allowed ranges, and once removed they cannot be recovered from the text; save them elsewhere, or fold the explanation into an adjacent field before repairing. Second, unrecognized backslash escapes inside strings are treated as literal characters. A Windows path written as D:\data contains \d, which is not a valid JSON escape sequence, and may come back as D:data. For any value that looks like a path, write double backslashes before repairing.

Advertisement

Frequently asked questions

Will the repair overwrite my original text?
Only when the repair fully succeeds. If the text still cannot be parsed afterwards, the tool keeps what you pasted and reports that it could not fix the document, so a half-repaired version never sits in the editor looking like a finished one. If the text is the only copy, duplicate it before repairing.
Are comments preserved?
No — they are deleted, because standard JSON has no comment syntax. If the comments documented field meanings, units or value ranges, that information is gone after the repair. Copy it somewhere else first, or convert the note into a regular field at the same level and then repair.
Does the repair convert non-ASCII text to \uXXXX?
No. Re-serializing writes characters out literally rather than escaping them into Unicode notation. If the target system accepts ASCII only, run the repaired document through the Unicode escape tool afterwards; the order can also be reversed, but repairing first means the escape step operates on clean input.
Why does the editor still report an error after repairing?
That means the text has structural damage beyond what the repair rules cover: most often a missing comma between two members, mismatched bracket counts, a string whose closing quote never appears, or content truncated during copy and paste. The error message names the line and shows the snippet, so start looking there and work outward.

Related tools

Advertisement