Fix JSON Online: Repair Rules, JavaScript Workflows, LLM Output, and Privacy

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 for production code, because bad input fails loudly. You are looking at a pasted payload and just want to see the object shape. It is annoying. That is where an online JSON fixer comes in: it turns common "almost JSON" into valid JSON so you can inspect, copy, or pass it thru 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

Always read the output once after repair before usage. A fixer might guess that the output would be syntactically valid but 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 outputs strict JSON text. It is different than formating or validation:

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 case of repair. They copy a JavaScript object from a test file, a config snippet, or the browser console and paste 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 type of repair as the intention is obvious. The input already describes the same object it just uses the wrong grammar.

#2. Comments in a config file

Comments are not allowed in JSON. Many config formats that look like JSON but are not JSON. JSONC, JavaScript config, VS Code settings, 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 usually return JSON inside markdown, which is useful in chat. The fence is not included in 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 has prose before the fence (e.g. "Here is the JSON:"), remove that prose first or only paste the fenced block. A repair parser can ignore trailing text after a complete value. Leading prose is ambiguous and should not be parsed as data.

The LLM-specific production workflow appears later in this article.

#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 convenient for inspection, but does not prove that the original data were complete. If the payload is coming from an API, go back to the source and get 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 suspect data. A fixer can serialize the parsed object . But it may lose the earlier value . If duplicate keys are important to your pipeline, consider a stricter validator or a schema-aware parser that flags 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"
}

If the error mentions an invalid escape sequence, inspect the backslashes and the source language before accepting an automatic repair. The JSON parse error guide covers escape and string failures in detail.

#NDJSON or multiple JSON documents

This is not one JSON document:

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

It is newline delimited JSON, or two JSON values separated. A repair tool may return the first complete value, ignoring the rest. That is not a bug. That 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 yourself before pasting a token, webhook payload, customer export or internal config to any online tool.

Some formatters POST your input to a server. It can leak secrets thru application logs, analytics programs, crash reports, CDN caches or request captures. It might look like a local editor but it still sends 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 reduces risk, but doesn’t relieve you of the responsibility to treat secrets with care. If the data is highly sensitive, please use a company approved local tool or run an offline script on a trusted machine.

See the privacy checklist later in this article to confirm local processing and redaction of a payload before sharing.

#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."

#Repair Broken JSON in JavaScript

For application code, make repair an explicit policy instead of a fallback hidden inside every JSON.parse() call. Strict-parse first, repair only when the caller allows it, then strict-parse the repaired text again.

import { jsonrepair } from 'jsonrepair';

function parseJson(text, { allowRepair = false } = {}) {
  if (typeof text !== 'string') {
    return { ok: false, kind: 'not_string' };
  }

  try {
    return { ok: true, repaired: false, value: JSON.parse(text) };
  } catch (parseError) {
    if (!allowRepair) {
      return { ok: false, kind: 'invalid_json', error: parseError.message };
    }

    try {
      const repairedText = jsonrepair(text);
      return {
        ok: true,
        repaired: true,
        repairedText,
        value: JSON.parse(repairedText),
      };
    } catch (repairError) {
      return {
        ok: false,
        kind: 'repair_failed',
        parseError: parseError.message,
        repairError: repairError.message,
      };
    }
  }
}

The call site owns the decision:

const pastedExample = parseJson(editorText, { allowRepair: true });
const paymentCommand = parseJson(requestBody, { allowRepair: false });

Return the repaired flag so the UI can display the changed text and logs can distinguish accepted JSON from recovered input. Never use eval() or new Function() as a repair shortcut; they execute code rather than parse data.

For fetch(), an HTML response, empty 204, or truncated body is a transport or contract problem. Inspect the status, content type, and raw text as described in JSON parse errors; do not run an API error page through a repair parser.

#Repair LLM JSON Output Without Trusting It

Model output often includes markdown fences, introductory prose, comments, python literals or a trailing comma. Think of cleanup and validation as two separate steps:

1. Prefer the provider's schema-constrained or structured-output feature.
2. Buffer the complete response when possible; an in-progress stream is incomplete JSON by definition.
3. Extract the intended fenced block or value. Do not guess across multiple candidate objects.
4. Strict-parse first, then repair syntax if your policy allows it.
5. Strict-parse the repaired text again.
6. Validate required fields, types, enums, and limits with JSON Schema or an application validator.
7. Refuse or require human review before a financial, permission, deletion, migration, or other state-changing action.

Here is the boundary in code:

import { jsonrepair } from 'jsonrepair';
import { z } from 'zod';

const Result = z.object({
  title: z.string(),
  severity: z.enum(['low', 'medium', 'high']),
});

const repairedText = jsonrepair(rawModelOutput);
const parsed = JSON.parse(repairedText);
const result = Result.parse(parsed);

Repair can fix grammar, but it can’t bring back a missing fact or prove that something made up is true. In the case of streaming UI previews, a partial parser can expose full prefixes, but the final value still needs a strict parse and schema validation once the stream is complete.

#Keep Sensitive JSON Local

Production payloads commonly contain bearer tokens, cookies, JWTs, webhook signatures, customer records, database URLs, internal hostnames, or trace data. When processing is local to the browser, the operation is performed in the page’s memory, and no request with the input is sent to a formatting or repair server.

Verify that claim with a harmless probe:

1. Open DevTools and select Network.
2. Clear existing entries and enable Preserve log.
3. Paste a unique fake value such as {"probe":"local-test-4937"}.
4. Run repair, formatting, validation, or diff.
5. Search request URLs and payloads for local-test-4937.
6. Optionally disconnect after the page loads and confirm the tool still works.

Browser local is safer but page scripts, extensions, screenshots, tickets, copied output are still part of the exposure path. For regulated or highly sensitive data, utilize an internal approved tool or a local CLI.

python3 -m json.tool response.json
jq . response.json
jq 'del(.headers.authorization, .cookie, .password)' response.json

If you pasted a live secret into an unapproved server-side tool, consider it exposed: rotate or revoke it, remove share links and copied tickets if you can, and follow your incident policy. The way the payload is formatted does not make the secret any less usable.

#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 on your browser and even then you must follow your own data handling rules. JSON Fix does the repair and format in your browser. You can verify in DevTools that clicking Repair & Format will not send your pasted JSON to a server.

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

A validator tells you if the text is strict JSON and where parsing failed. A fixer attempts to recover from common mistakes and returns a valid JSON value. Use the fixer to clean up almost-JSON, then use validation to make sure 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.

#How do I repair broken JSON in JavaScript?

Try JSON.parse() first. For an explicitly repairable source, pass the text through a structural repair library such as jsonrepair, strict-parse the returned text, validate the resulting value, and report that repair occurred.

#Does fixjson.org upload the JSON I paste?

The fix is intended to run in the browser. You can verify it with DevTools using a unique fake payload and checking that no Fetch/XHR request contains the value. Use local tooling approved for regulated or particularly sensitive data.

#What should I do if I pasted an API key or token into an online tool?

Rotate or revoke it instead of trusting a promise that it wasn’t stored. Also remove share links and copied payloads from tickets or chats if possible and follow your organization's incident process.

#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:

• JSON parse errors - diagnose the input before deciding to repair it.
• How to format and validate JSON - confirm repaired output and inspect it safely.
• How to stringify JSON - fix object serialization at the producer.
• JSON Diff - compare two JSON documents after cleanup.
• YAML to JSON - convert YAML into strict JSON.
• Base64 Decoder - decode Base64-encoded JSON payloads such as JWT claims.

#Sources

• RFC 8259: The JavaScript Object Notation Data Interchange Format
• MDN: JSON.parse()
• MDN: JSON.stringify()
• jsonrepair - open-source JSON repair parser for JavaScript
• json-repair - JSON repair library for Python
• Zod - schema validation for JavaScript and TypeScript values.

Last reviewed August 2026.