Home › Fix Truncated JSON

Fix truncated JSON — recover what arrived, invent nothing

Direct answer: when a JSON document is cut off — an LLM response that hit the token limit, a timed-out API call, a partial download — this tool recovers the largest structurally complete prefix: open objects and arrays are closed, the incomplete tail is dropped and listed, and no key, value, or element is ever made up. You also get a Recovery Note stating exactly what was cut.

Truncated JSON Recovery

Recovery never invents data: whatever was cut off is dropped and listed, open structures are closed, and any value that had to be force-closed is flagged as suspect. Processed locally — nothing is uploaded.

How recovery works

  1. Paste the cut-off JSON, or drop the partial file onto the panel.
  2. Press Recover. The scan tracks the open structure and the last complete boundary.
  3. Read the Recovery Note: what was cut, what was closed, what was dropped, and any suspect value.
  4. Copy or download the recovered document — valid JSON containing only data that was fully present.

The honesty rule is the product. A truncated number is the clearest case: if the stream stopped at {"count": 12, the true value might be 12, 1234, or 12.5 — any tool that hands you back "12" as fact is guessing with your data. This tool drops the pair and tells you it did. The same logic applies mid-key, mid-string, mid-escape, after a comma, and after a colon — each position class is handled and reported.

If your input turns out to be complete and valid, the tool says so — there is nothing to recover. And if the truncation is inside a line-delimited file, use NDJSON Salvage instead: it recovers per line, so one cut line costs you one record, not the tail of the file.

Frequently asked questions

What does recovery do with the incomplete part?

It discards it — and lists it. A token cut in half (half a string, half a number, a key with no value) cannot be completed honestly: "12" at the cut might be the start of 1234. The incomplete token, and the pair or element it belonged to, are dropped and named in the Recovery Note. Open objects and arrays are then closed in order, giving you the largest prefix of your data that was fully present.

Is the recovered output guaranteed to be a subset of my data?

Yes — that is the design rule. Every key, value and array element in the output was completely present in the input. One flagged exception: if a string value lost only its closing quote, recovery closes it and marks that value "treat as suspect" in the note, because the string's own content may have been cut too.

What is the difference between this and JSON Repair?

Repair fixes syntax mistakes anywhere in a complete paste and will complete an unambiguous cut token (for example closing an unterminated string). Recovery is the stricter tool for documents that end mid-stream: it assumes the end is missing data, not a typo, and refuses to complete any token that was cut. Use Repair for messy-but-complete JSON; use Recovery when the stream was cut.

Why did my JSON get truncated in the first place?

The usual causes: an LLM hit its output token limit mid-response; an API call timed out or the connection dropped during a large response; a log or download was cut short; or a buffer/string limit somewhere in a pipeline sliced the payload. The fix at the source is more tokens, pagination, or streaming — this tool recovers what you already received.