Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool

When Good JSON Goes Bad: Recovering Corrupted JSON Files

If you need to recover a corrupted JSON file, start by answering one question before you edit anything: is the file actually malformed JSON, or did you receive the wrong payload entirely? Many "corrupted JSON" incidents turn out to be truncated writes, HTML error pages saved as `.json`, or text that was decoded with the wrong character set.

The fastest reliable workflow is simple: preserve the original file, validate it, map the first parser error to the most likely damage, repair the smallest possible section, and validate again. That is usually much faster than guessing and rewriting the whole document from scratch.

Start With Triage, Not Editing

Make a copy first.
Work on a duplicate so you can compare versions and roll back when a repair attempt makes the structure worse.
Confirm the file is supposed to be JSON.
If the content starts with <html, <!DOCTYPE, or an error banner, your problem is probably upstream. The file may never have contained JSON at all.
Validate once and record the first error.
The first parser error is usually the most useful one. Feed the file into a validator or formatter that reports the earliest failing location instead of trying random edits.
Check the end of the file.
A surprising number of broken JSON files are simply cut off mid-object or mid-array because a write or download stopped early.
Only repair what you can justify.
Close open braces, remove invalid commas, or restore missing quotes when the intended structure is obvious. Do not invent missing business data unless you have a schema or backup to confirm it.

Current JSON Rules That Matter

Standard JSON is still strict. According to RFC 8259, JSON exchanged between systems should use UTF-8, object keys must be double-quoted strings, and comments or trailing commas are not valid JSON. A leading BOM can appear in real files; some parsers ignore it, but it is still worth stripping once if the first character looks suspicious.

What the Error Usually Means

Unexpected token < usually means you saved an HTML response, login page, proxy error, or stack trace instead of JSON.
Unexpected end of JSON input or an end-of-data error usually means the file is empty or truncated.
Expected property name or a message about double-quoted property names usually means you have JavaScript-object syntax, comments, or single quotes instead of strict JSON.
Errors near a closing } or ] often point to a trailing comma or an extra closing bracket.
Bad control character in string literal often means a raw tab, newline, or broken escape sequence inside a quoted string.
If the file parses but values look like caf\\u00c3\\u00a9, you likely have an encoding or decode problem rather than JSON syntax corruption.

MDN's current JSON.parse error reference is useful when the exact wording looks unfamiliar, but the practical pattern is the same: fix the first structural break, then validate again.

A Practical Recovery Workflow

Preserve the original bytes.
Rename the damaged file, duplicate it, and keep the untouched copy in case you later discover the repair introduced silent data changes.
Localize the first break.
Paste the file into a JSON formatter or validator and note the first line and column. On large files, inspect around that location first instead of scrolling blindly from the top.
Repair structure in this order:
Quotes, brackets and braces, commas and colons, then escapes and encoding.
Prefer deleting incomplete fragments over guessing missing values.
If the last object in an array is cut off halfway through, remove that incomplete record and close the array unless you can reconstruct the missing fields from logs, schema defaults, or a backup.
Revalidate after every meaningful edit.
Multiple tiny fixes with repeated validation are safer than a large rewrite that changes both structure and content at once.
Salvage a valid subset if the whole file cannot be restored.
For append-heavy data, it is often better to recover all complete objects up to the point of corruption and emit fresh JSON than to perfectly recreate missing bytes.

Useful Rule of Thumb

A JSON formatter is best used as a locator and verifier, not as a magic repair engine. Use it to find the first structural failure, fix that failure deliberately, and then confirm the repaired output is valid before you overwrite the source file.

Practical Recovery Examples

Example 1: HTML Was Saved Instead of JSON

What You Found:

<!DOCTYPE html>
<html>
  <head><title>502 Bad Gateway</title></head>
  <body>Upstream server error</body>
</html>

What It Means:

This is not corrupted JSON. The upstream service returned an HTML error page, and the client saved it as if it were JSON.

Recovery Strategy:

Check the HTTP status code, auth state, or reverse proxy logs.
Repeat the request until you obtain the real JSON payload.
Do not try to "fix" this file with syntax edits.

Example 2: Truncated Array or Object

Truncated JSON:

{
  "users": [
    {
      "id": 1,
      "name": "John Smith",
      "email": "john@example.com"
    },
    {
      "id": 2,
      "name": "Jane Doe",

Safe Recovery:

{
  "users": [
    {
      "id": 1,
      "name": "John Smith",
      "email": "john@example.com"
    }
  ]
}

The second record is incomplete, so the safe repair is to keep only the fully known object and close the structure. If you can recover Jane Doe's missing fields from logs or a previous export, add them back explicitly. If not, do not fabricate them.

Example 3: JavaScript Object Syntax Masquerading as JSON

Invalid JSON:

{
  server_config: {
    // local override
    host: 'api.example.org',
    port: 443,
    retry: true,
  }
}

Recovered JSON:

{
  "server_config": {
    "host": "api.example.org",
    "port": 443,
    "retry": true
  }
}

This pattern is common when a config file was copied from JavaScript, JSON5, or a hand-edited snippet. Remove comments, use double quotes, and delete trailing commas.

Example 4: Valid JSON, Wrong Text Encoding

Syntactically Valid but Corrupted Data:

{
  "product": "caf\u00c3\u00a9 mug"
}

Recovered JSON:

{
  "product": "caf\u00e9 mug"
}

JSON supports Unicode text. The problem here is not that the file contains non-ASCII characters; the problem is that the text was decoded or re-encoded incorrectly earlier in the pipeline. If possible, recover from the original UTF-8 source instead of manually replacing characters one by one.

When Full Recovery Is Not Realistic

The file was overwritten and the missing bytes are gone with no backups or logs.
Key names or string values were damaged in the middle and you cannot infer the original text safely.
The data order matters and you cannot prove which records were partially written or duplicated.
You only have a derived export, not the source of truth that produced it.

In those situations, the realistic goal is not perfect reconstruction. It is to salvage the confirmed subset, document what was lost, and rebuild the rest from backups, event logs, or the upstream system that originally generated the JSON.

What Not to Do

Do not replace every single quote blindly. Apostrophes inside string values can make that destructive.
Do not use regular expressions to rewrite deeply nested JSON wholesale.
Do not strip all non-ASCII text. Modern JSON supports Unicode just fine.
Do not keep editing after the first valid parse without checking whether the data itself still makes sense.

How To Prevent the Next Corruption

Write to a temporary file and rename it atomically after validation succeeds.
Validate JSON before saving, deploying, or importing it into another system.
Keep versioned backups for files that matter.
Store append-heavy logs as NDJSON or JSONL when one-record-per-line is acceptable.
Log upstream HTTP status codes so HTML error pages are easier to spot immediately.

Recovering corrupted JSON is mostly a discipline problem, not a mystery problem. Preserve the original, identify the first real structural failure, repair only what you can justify, and validate after every edit. That approach gives you the best chance of keeping the data you can trust while avoiding silent corruption you introduce yourself.

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool