JSON Tools

JSON Repair — Fix Invalid JSON Online

Paste JSON that almost parses — single quotes, trailing commas, comments, a truncated tail — and get valid, formatted JSON back.

In short

Fix broken JSON online: single quotes, trailing commas, comments, unquoted keys, Python literals and truncated documents repaired into valid JSON.

By NaveenKumar T · Updated 10 Sep 2026

Learn: What is JSON? A Practical Introduction

Fixes quotes, commas, comments and unquoted keys
Completes truncated documents
Converts Python True / False / None

Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →

Example

JSON Repair: input and output

A configuration file that picked up a little of every language it passed through — and then got cut off mid-string.

Broken JSON

{
  name: 'checkout-service',
  "version": "2.3.0",   // bumped for the hotfix
  'retries': 3,
  "flags": [ 'beta', 'canary', ],
  "enabled": True,
  "owner": None,
  "notes": "missing the closing quote and brace

Repaired JSON

{
  "name": "checkout-service",
  "version": "2.3.0",
  "retries": 3,
  "flags": [
    "beta",
    "canary"
  ],
  "enabled": true,
  "owner": null,
  "notes": "missing the closing quote and brace"
}

Every defect is resolved in one pass: the unquoted `name` key, four single-quoted strings and keys, the `//` comment, the trailing comma after 'canary', the Python True and None literals, and the unterminated final string. The string is closed where the input stopped and the missing brace is added — nothing beyond that is invented, so the last field is exactly as complete as the input was.

Learn more

What gets repaired

Most "invalid JSON" isn't corrupt — it is JavaScript, Python, a config file with comments, or a language model's best guess at JSON. The repairer walks the document with a tolerant parser, rewrites the constructs that JSON does not allow, and then parses and re-serializes the result. That last step is the important one: the output is not patched text, it is a document that has provably round-tripped through a real JSON parser, formatted with the indentation you choose.

The repairs fall into three groups. Quoting and punctuation problems are the largest: single or curly quotes instead of straight double quotes, keys left unquoted the way a JavaScript object literal writes them, a comma after the last element, or a comma missing between two members. Literal problems come next — Python's True, False and None, JavaScript's undefined, and Mongo shell wrappers like ObjectId("…") and NumberLong(2), all of which are rewritten to the nearest legal JSON value. Structural problems are the third group: markdown code fences around a response, a stray control character inside a string, records separated by newlines instead of commas, and documents that simply stop before they finish.

Common defects and what the repairer produces
Problem	Example input	Result
Single-quoted strings and keys	{'a': 1}	{"a": 1}
Unquoted keys	{a: 1}	{"a": 1}
Trailing commas	{"a": 1,}	{"a": 1}
Comments	{"a": 1 /* note */}	{"a": 1}
Python literals	{"ok": True, "x": None}	{"ok": true, "x": null}
JavaScript undefined	{"a": undefined}	{"a": null}
Missing comma	{"a": 1 "b": 2}	{"a": 1, "b": 2}
Smart / curly quotes	{“a”: ‘b’}	{"a": "b"}
Truncated document	{"a": [1, 2	{"a": [1, 2]}
Newline-delimited records	{"a":1}⏎{"b":2}	[{"a":1},{"b":2}]
MongoDB wrappers	{"n": NumberLong(2)}	{"n": 2}
Markdown code fence	```json … ```	the JSON inside the fence

What it cannot fix

A repairer can restore syntax; it cannot restore meaning. If a document was truncated, the missing records are gone — closing the brackets only makes the fragment parseable. If two root values sit on one line with nothing to separate them, or the input is an HTML error page, a stack trace or prose, there is no structure to recover and you get an error with the position where the parse gave up.

There are also repairs that succeed but change semantics, and those deserve a second look. NaN and Infinity survive as strings, because JSON has no way to express them. Hexadecimal and leading-zero numbers such as `0x1F` and `007` are kept as strings for the same reason. Numbers are re-parsed as doubles, so 64-bit identifiers past 2^53 quietly lose their last digits. And nothing here validates against a schema: a document can be perfectly valid JSON and still be wrong for your API.

The safe workflow is repair, then verify. Run the repaired output through the JSON validator or open it in the JSON viewer and check the fields the repair touched — especially the tail of a truncated document and any numeric field. If you are repairing two versions of the same payload, the JSON compare tool will show you exactly what the repair changed.

Where broken JSON comes from

Four sources account for almost everything people paste into a JSON fixer. Language model output is the fastest-growing one: models emit fenced code blocks, trailing commas and unquoted keys, and they frequently stop mid-document when a token limit is hit — which is exactly the truncated case handled above. Hand-edited configuration is the classic one: a developer adds a `//` comment or leaves a trailing comma after deleting the last entry, and the deploy fails.

The third is copy-paste from a language runtime. A Python dict printed to a terminal uses single quotes and True/False/None; a JavaScript object literal has unquoted keys and maybe an `undefined`; a Mongo shell dump wraps values in ObjectId() and NumberLong(). All of them look like JSON and none of them parse. The fourth is transport damage — a log line cut at a fixed width, a partial response from a request that timed out, or a file that filled a disk mid-write.

Knowing which of the four you are dealing with tells you how much to trust the result. The first three are formatting problems, and a repaired document is as complete as the original. The fourth is data loss, and the repair is a way to read what survived — not a reason to believe nothing is missing. When you need to know whether a large payload was truncated because it was simply too big, the JSON size calculator will tell you what the document actually weighs.

Help

Frequently asked questions

Everything you need to know about the JSON Repair.

01What does the repairer do with a document that was cut off?

It closes what is open, where the input stops. An unterminated string is closed at the last character you have, and any open arrays and objects are closed in order — so `{"a": [1, 2` becomes `{"a": [1, 2]}`. That makes the document parseable, but it does not recover data that never arrived: if a download or log line was truncated mid-record, treat the last record as suspect rather than trusting it.

02Why did two JSON objects on the same line fail to repair?

Newline-delimited JSON is understood — objects on separate lines are collected into an array — but two root values separated only by a space, like `{"a":1} {"b":2}`, are ambiguous and raise an error at the position of the second `{`. Put each record on its own line and the repair succeeds. The same rule is why free-form text or an HTML error page can't be repaired: there is no JSON structure to recover.

03What happens to NaN, Infinity, and very large integers?

JSON has no NaN or Infinity literals, so they are preserved as the strings "NaN" and "Infinity" rather than silently becoming null — check any numeric field that came from a serializer which emitted them. Integers are re-parsed as IEEE-754 doubles, so a value beyond 2^53 (about 9.007e15) loses precision; if you are repairing a document full of 64-bit IDs, they should have been quoted strings in the first place.

04Will repairing change values that were already valid?

Numbers are normalized because the document is parsed and re-serialized: `1.40` becomes `1.4`, `1e3` becomes `1000`, and `0x1F` — which isn't legal JSON — is kept as the string "0x1F". Strings, booleans, nulls and key order are preserved exactly. If you need byte-identical output for anything already valid, run it through the [JSON formatter](/json-formatter) instead.

05Can it fix JSON that has been escaped inside a string?

Not directly. A value like `"{\"a\":1}"` is a perfectly valid JSON string that happens to contain JSON, so there is nothing to repair — the repairer leaves it alone. Use the [string to JSON](/string-to-json) tool to unescape it first, then repair the result if it still doesn't parse.

Keep working