JSON Repair Tool

Almost all invalid JSON has a human in its history. Files that machines write and machines read are reliably valid, because serialisers do not make syntax mistakes. Breakage comes from editing: someone adds a key to a config by hand, copies an object out of JavaScript source, assembles a payload in a string template, or truncates a file while pasting. The specific errors are consistent enough that automatic repair works — they are the habits of languages more forgiving than JSON, applied to a format that is not.

The reliable fix is to stop hand-writing JSON. Generate it with your language's serialiser, which cannot produce a trailing comma. Give your editor a JSON schema so it flags problems as you type. Validate config files in CI so a broken one fails a build instead of a deployment. And where a file genuinely must be edited by people, consider a format designed for that — YAML, TOML, or JSONC all allow comments and forgive trailing commas, which is exactly what hand-edited configuration needs.

The three mistakes that account for most invalid JSON, all of which come from JavaScript habits that JSON does not allow: a trailing comma after the final item in an object or array, strings written with single quotes, and object keys left unquoted. Each is legal in a JavaScript object literal and rejected by every JSON parser, which is why hand-edited config files and JSON copied out of source code fail so often.

No, and it is important to know the boundary. Repair handles unambiguous, mechanical mistakes. It cannot resolve genuine structural damage — a truncated file missing its closing braces, two documents concatenated together, or a payload where a value is simply absent — because fixing those requires guessing what the data was meant to be. If the output still fails to parse, run it through the validator to see the exact line where the structure gives up.

Because every language people write nearby permits it. JavaScript, Python, Rust, and Go all allow a trailing comma, and it is actively good practice there — it keeps diffs clean when you add a line. Editors and formatters will even add one for you. JSON is the outlier, so the habit produces invalid files constantly. This is also why relaxed formats exist: JSON5 and JSONC allow trailing commas and comments precisely because so many JSON files are edited by hand.

It is safe in the sense that nothing is executed, but treat a broken API response as a signal rather than something to patch. Valid JSON is the one thing an API is supposed to guarantee, so a malformed response usually means something real: a truncated payload from a timeout, an error page returned with the wrong content type, or a serialisation bug on the server. Repairing it locally lets you read what arrived, which is useful for diagnosis — but the fix belongs upstream.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.