← All articles
Updated May 29, 202610 min read

How Online JSON Repair Works: Rules, Limits, and Safer Fixes

Learn how online JSON repair tools fix trailing commas, single quotes, unquoted keys, comments, Python literals, and LLM code fences without hiding risky data changes.

JSON.parse() is strict on purpose. It accepts JSON, not JavaScript object literals, not Python dictionaries, not a ChatGPT answer wrapped in a code block, and not a half-copied API response with a dangling comma.

That strictness is good in production code because bad input fails loudly. It is annoying when you are staring at a pasted payload and just need to see the object shape. An online JSON fixer is for that middle ground: it turns common "almost JSON" into valid JSON so you can inspect it, copy it, or send it through a stricter validator.

The important part is the boundary. A good fixer repairs syntax. It should not pretend to understand your business rules, your API schema, or whether "price": "19.99" should have been a number.

The Short Version

Use an online JSON fixer when the input is close to valid JSON and the mistake is mechanical:

Broken pattern What a repair pass usually does
{ name: 'Ada', } Quotes the key, converts single quotes, removes the trailing comma
{ "active": True, "deleted": False } Converts Python booleans to JSON true and false
{ "value": undefined } Converts undefined to null because JSON has no undefined value
// comment or /* comment */ Removes comments outside strings
Markdown code fence around the payload Extracts the JSON inside a full fenced block
{ "items": [1, 2, 3 Closes the open array and object so you can inspect the partial value

After repair, always read the output once before using it. If a fixer had to guess, the output may be syntactically valid but still semantically wrong.

What Is an Online JSON Fixer?

An online JSON fixer is a browser tool that takes invalid JSON-like text, runs a repair parser, and returns strict JSON text. It is different from a JSON validator:

Tool Best for Output
JSON validator Confirming a payload follows the JSON grammar Pass/fail plus an error location
JSON formatter Pretty-printing already-valid JSON Same data, easier to read
JSON fixer Recovering common JSON syntax mistakes A repaired JSON value serialized back to strict JSON

In practice, you often use all three in one workflow:

  1. Paste the broken input into JSON Fix.
  2. Run repair and format.
  3. Review the cleaned output.
  4. Validate the result strictly before you save it, commit it, or feed it to code.

That last validation step matters. Repair is a convenience layer, not a data-quality guarantee.

Why Regex-Based JSON Repair Breaks

The naive way to fix JSON is a pile of regular expressions:

text
  .replace(/,\s*}/g, '}')
  .replace(/,\s*]/g, ']')
  .replace(/'/g, '"');

This works for tiny demos and then bites you on real data.

For example, a broad comment-stripping regex can damage a URL:

{
  "callback": "https://api.example.com/v1/events"
}

The // inside https:// is not a JSON comment. It is part of a string value. A real fixer has to know whether it is currently inside a string, inside an object key, inside an array, or between values.

That is why good tools use a repair parser instead of blind text replacement.

How JSON Fix Repairs a Broken Payload

The repair flow on JSON Fix is intentionally boring in a good way. The tool runs in the browser, parses the input into a JavaScript value, and serializes that value back with JSON.stringify().

Here is the practical sequence:

  1. Trim a full markdown fence. If the entire pasted input is an unlabeled fenced block or a fenced block labeled json, javascript, or js, the fence is removed before parsing.
  2. Tokenize leniently. The lexer recognizes strict JSON tokens, plus common non-JSON tokens such as single-quoted strings, identifiers, comments, True, False, None, undefined, +12, and 0xFF.
  3. Parse with recovery. The parser still follows the JSON grammar, but in repair mode it can skip stray commas, accept unquoted keys, tolerate missing commas, and close an unfinished object or array at the end of input.
  4. Normalize the value. The repaired value is printed with JSON.stringify(value, null, 2) or a 4-space indent if you choose that option.
  5. Return strict JSON. The output contains double-quoted strings, lowercase booleans, null, no comments, no trailing commas, and no markdown wrapper.

The key detail: the repair parser works with structure, not just characters. It can remove a comment between properties without touching the same // sequence inside a string.

Examples of JSON Repair in the Real World

1. JavaScript object literal pasted as JSON

This is probably the most common repair case. Someone copies a JavaScript object from a test file, config snippet, or browser console and pastes it into a JSON parser.

{
  name: 'Ada Lovelace',
  active: True,
  skills: ['math', 'notes',],
}

The repaired JSON is:

{
  "name": "Ada Lovelace",
  "active": true,
  "skills": [
    "math",
    "notes"
  ]
}

Several fixes happened at once:

  • name, active, and skills became quoted property names.
  • Single-quoted strings became JSON strings.
  • True became true.
  • The trailing comma after "notes" was removed.

This is a safe kind of repair because the intent is clear. The input already describes the same object; it just uses the wrong grammar.

2. Comments in a config file

JSON does not allow comments. Many config formats look like JSON but are not JSON: JSONC, JavaScript config, VS Code settings, and hand-written examples in documentation.

{
  "env": "staging",
  // Temporary while QA tests the login flow.
  "debug": true,
  "retries": 3,
}

Repair output:

{
  "env": "staging",
  "debug": true,
  "retries": 3
}

This is usually fine for debugging or conversion. For a committed config file, the better fix is to use the right file format: strict .json if comments are not allowed, or .jsonc / .js if comments are part of the workflow.

3. LLM output wrapped in a code fence

AI tools often return JSON inside markdown because that is helpful in chat. The fence is not part of the JSON document.

```json
{
  "title": "Incident summary",
  "severity": "medium",
}
```

Repair output:

{
  "title": "Incident summary",
  "severity": "medium"
}

One caveat: copy the JSON block itself. If the response includes prose before the fence, such as "Here is the JSON:", remove that prose first or paste only the fenced block. A repair parser can ignore trailing text after a complete value, but leading prose is ambiguous and should not be treated as data.

For a full workflow, see Repair LLM JSON Output.

4. Truncated JSON from a partial copy

Sometimes the payload is not wrong; you just did not copy all of it.

{
  "users": [
    { "id": 1, "name": "Ada" },
    { "id": 2, "name": "Grace"

A repair parser can close the open object and array:

{
  "users": [
    {
      "id": 1,
      "name": "Ada"
    },
    {
      "id": 2,
      "name": "Grace"
    }
  ]
}

This is useful for inspection, but it is not proof that the original data was complete. If the payload came from an API, go back to the source and fetch it again.

5. Non-JSON numbers from JavaScript

JSON numbers are stricter than JavaScript number literals. There is no leading plus sign and no hexadecimal notation.

{
  "offset": +12,
  "mask": 0xFF
}

Repair output:

{
  "offset": 12,
  "mask": 255
}

That conversion is syntactically reasonable, but review it. If the original string was meant to preserve the notation "0xFF" rather than the numeric value 255, repair cannot know that.

What an Online JSON Fixer Should Not Hide

Some inputs should make you slow down.

Duplicate keys

JSON parsers usually keep the last value when an object has the same key twice:

{
  "role": "reader",
  "role": "admin"
}

That is valid JSON syntax, but it is suspicious data. A fixer can serialize the parsed object, but the earlier value may be lost. If duplicate keys matter in your pipeline, use a stricter validator or a schema-aware parser that reports them.

Missing business fields

This can be repaired syntactically:

{ "id": 42, "email":

But the repaired output may be:

{
  "id": 42,
  "email": null
}

That does not mean null is a correct email value. It only means the parser reached the end of input and needed a placeholder so the object could close.

Invalid escapes inside strings

This is where repair becomes more delicate:

{ "path": "C:\new\reports\q1.json" }

Depending on the exact characters, a parser may treat \n as a newline escape and unknown escapes as recoverable text. The output may not preserve the path you intended. For paths and regular expressions, the safer fix is to escape backslashes yourself:

{
  "path": "C:\\new\\reports\\q1.json"
}

See Bad Escaped Character in JSON if the error mentions an invalid escape sequence.

NDJSON or multiple JSON documents

This is not one JSON document:

{ "id": 1 }
{ "id": 2 }

It is newline-delimited JSON, or two separate JSON values. A repair tool may return the first complete value and ignore the rest. That is not a bug; it is a sign that you need an NDJSON parser or you need to wrap the records in an array.

When to Use an Online JSON Fixer

Situation Good fit? Reason
Debugging a one-off API payload Yes You need a readable object quickly
Cleaning LLM-generated JSON Yes Fences, comments, Python literals, and trailing commas are common
Converting a JS object literal into JSON Yes Quote style and key quoting are mechanical
Repairing production ingestion No Put a tested repair library in the pipeline and log every repair
Handling regulated data Be careful Use a local/browser-only tool, or run an offline script
Enforcing an API contract No Use strict parsing plus JSON Schema validation

The rule I use: repair human-generated mess, reject machine-to-machine contract violations unless you intentionally support repair.

Privacy: Does the JSON Leave Your Browser?

This is the first question to ask before pasting a token, webhook payload, customer export, or internal config into any online tool.

Some formatters POST your input to a server. That can expose secrets through application logs, analytics tools, crash reports, CDN caches, or request captures. The page may look like a local editor while still sending your data away.

JSON Fix runs the repair in your browser. The editor calls the local repair function, formats the value, and updates the output panel. You can verify that yourself:

  1. Open DevTools.
  2. Go to the Network tab.
  3. Paste a small test payload.
  4. Click Repair & Format.
  5. Confirm that no request containing your JSON is sent.

Browser-local processing lowers the risk, but it does not remove your responsibility to handle secrets carefully. For highly sensitive data, use a company-approved local tool or run an offline script on a trusted machine.

For more detail, read Why You Shouldn't Paste Sensitive JSON Into Online Tools.

A Safer Repair Workflow

Use this checklist when the output matters:

  1. Keep the original input. Do not overwrite the broken payload until you understand the change.
  2. Repair once. Avoid repeatedly repairing already-repaired output; that makes it harder to explain what changed.
  3. Review suspicious conversions. Pay attention to undefined -> null, 0xFF -> 255, missing values, and unclosed strings.
  4. Validate strictly. Run the repaired text through a strict validator after the repair pass.
  5. Validate meaning. If the payload feeds an API, check it against JSON Schema or your application-level contract.
  6. Fix the source when possible. A repair tool is great for triage. The durable fix is usually in the producer that generated bad JSON.

This is the difference between "I made the parser stop yelling" and "the data is safe to use."

Frequently Asked Questions

How do I fix JSON online?

Paste the broken JSON into a browser-based fixer like JSON Fix, run Repair & Format, then review the output. It can handle common syntax mistakes such as trailing commas, single quotes, unquoted keys, comments, Python literals, undefined, markdown code fences, and unclosed objects or arrays.

Does online JSON repair change my data?

It can. Safe-looking repairs such as single quotes to double quotes usually preserve intent, but conversions like undefined to null, 0xFF to 255, or closing a truncated object are best-effort guesses. Treat the output as repaired syntax, not verified business data.

Is it safe to paste sensitive JSON into an online fixer?

Only if the tool runs locally in your browser, and even then you should follow your own data-handling rules. JSON Fix processes repair and formatting client-side; you can confirm in DevTools that clicking Repair & Format does not send your pasted JSON to a server.

What is the difference between a JSON fixer and a validator?

A validator tells you whether the text is strict JSON and where parsing failed. A fixer tries to recover from common mistakes and returns a valid JSON value. Use the fixer to clean up almost-JSON, then use validation to confirm the result is strict JSON.

Can an online fixer repair AI-generated JSON?

Yes, if the issue is syntax: markdown fences, trailing commas, comments, single quotes, unquoted keys, or Python-style True / False / None. If the model omitted required fields or invented values, repair cannot know the correct answer.

Fix JSON Online Now

Paste the payload into JSON Fix when you need a quick browser-local repair pass. It is most useful for:

  • Broken JSON copied from logs, docs, chat, or test files.
  • LLM output that looks like JSON but is wrapped in markdown.
  • JavaScript-style object literals that need strict JSON output.
  • API responses you want to inspect before writing a real fix.

Related guides:

Sources

Last reviewed July 2026.