Skip to main content
CuteJSON
↑↓ Navigate Enter Select Esc Close

How to fix broken JSON automatically, and see every change

Published 2 min read By Akash Kinkar Pandey

A document copied out of a JavaScript source file, a commented config, or a hand edited fixture is often almost JSON: unquoted keys, single quotes, a trailing comma, maybe a comment explaining what a field is for. None of that is valid JSON, and fixing it by hand in a large file is tedious and easy to get wrong.

What the JSON repair tool fixes

Paste the broken document and press Repair. It handles unquoted object keys, single quoted strings, trailing commas, comments (both // and /* */), wrong case keywords like True and NULL, and the JavaScript values NaN, Infinity and undefined, which have no JSON equivalent and become null.

Why it lists every change instead of just fixing quietly

Most repair tools fix silently and hand back a result, which teaches you nothing and hides the cases where the fix was not what you actually meant. This one lists every change with its line and column, so you can check the result rather than trust it blindly. Paste this:

{
  // account info
  name: 'ana',
  role: 'admin',
  active: True,
  meta: undefined,
}

and Repair returns:

{ "name": "ana", "role": "admin", "active": true, "meta": null }

along with a list naming exactly what happened: the comment was removed, name and role gained quotes, both single quoted strings became double quoted, True was replaced with true, undefined became null, and the trailing comma was removed. Ten problems, ten line-numbered entries.

The one change that is called out separately

Removing a comment or converting quote style changes the spelling of your document, not its meaning. Replacing undefined with null is different: it changes what the data actually says, because JSON has no way to express “this key existed with no value.” The repair tool flags that distinction in its own message rather than lumping it in with the punctuation fixes, so you notice it rather than skim past it.

When it cannot help

If a document is broken in a way that cannot be rescued, such as a bracket that never closes, the tool says so and shows the remaining error instead of returning something that still will not parse. A repair tool that always returns success on unrecoverable input is worse than one that admits it could not finish.

Back to all posts