Home › Guides › How deterministic JSON repair works (and why we don’t use AI)

How deterministic JSON repair works (and why we don’t use AI)

Direct answer: a tolerant parser reads your document the way a strict one does — but when it meets a known defect, it applies a named, fixed rule instead of giving up: strip the fence, quote the key, remove the trailing comma, convert the literal. Every application is logged with its position, so output and report reconcile exactly. There is no AI in the loop, and where no rule honestly applies, the tool fails instead of guessing.

See the rule pipeline work — report included

Processed in your browser, so big pastes don't freeze the page. Nothing is uploaded — check your browser's network tab if you'd like to verify.

The pipeline, in order

  1. Envelope removal. A byte-order mark, markdown code fences, and prose before or after the document are located and removed — as the first report rows, not as invisible preprocessing.
  2. Tolerant scan. A scanner walks the text once, tracking the open-structure stack (objects, arrays), string state, and positions. It is iterative rather than recursive, so pathological nesting cannot blow a call stack.
  3. Named rules, fixed order. Each defect class has exactly one rule: convert single-quoted strings; quote unquoted keys; add a missing comma or colon; remove a trailing or stray comma; remove comments; map True/False/None/undefined/NaN/Infinity to their JSON counterparts; escape raw control characters in strings; repair malformed numbers; close unterminated strings and unclosed containers at the end.
  4. The log is the product. Every rule application appends a report row: number, line, column, JSON path, rule name in plain language, and a before/after snippet. If the output differs from your input, the report accounts for the difference — all of it.
  5. Honest exits. Three outcomes only: repaired (with the report), already valid (empty report), or cannot be repaired deterministically — with the location and reason. Prose that is not JSON, and values that are simply absent, end in the third outcome.

Two protections that are easy to miss

Duplicate keys are preserved. Strict parsers quietly keep the last value and drop the rest — data loss disguised as tidiness. This tool keeps both entries in order and flags the duplicate as a note in the report (an observation, not a change), so you decide what your application should do with it.

Numbers keep their source text. A parsed double cannot represent a 30-digit ID or the exact decimal you were sent. Numbers are carried through as their original text, so repair never introduces rounding that was not in your input.

Why not AI?

Repair is a strange place to want creativity. The input is a contract: another machine will consume the output believing it is your data. An AI asked to "fix this JSON" optimises for output that looks fixed — and its failures are precisely the dangerous kind, values altered plausibly and silently. A rule pipeline's failures are the safe kind: it stops and says where. That asymmetry — auditable success, honest failure, and no silent middle — is the entire design. It is also why the truncated-document tool is stricter still: where repair will close an unterminated string by rule, recovery treats the tail as missing data, drops the incomplete token, and flags the one value it had to force-close as suspect.

Verify it yourself

Do not take any of this on faith — the site is built to be checked. Open your browser's network tab and repair something sensitive: no request carries your input anywhere. Paste a document with a duplicate key or a 30-digit number and watch the report. Paste plain prose and watch it refuse. Those three experiments demonstrate the claims better than this page can argue them.

Frequently asked questions

What does "deterministic repair" mean?

The repair is a fixed pipeline of named rules applied by a parser — no AI, no probability, no per-run creativity. The same input always yields the same output and the same report. Every rule application is logged with its location, so the full difference between your input and the repaired output is accounted for, line by line.

Why not just use AI to fix JSON? It seems smarter.

Because the failure mode matters more than the success rate. A probabilistic fixer can return plausible JSON that parses — with a value quietly altered, a key renamed, a number rounded. For data you intend to feed a machine, a repair you cannot audit is worse than an honest failure. Deterministic rules either fix a defect by a stated rule or refuse; there is no third, silent outcome.

What can deterministic repair never fix?

Anything whose correct value is not present in the input: a missing value, the tail of a truncated document, a key the producer never sent. Rules operate on the text that exists. That boundary is deliberate — crossing it would mean inventing data, and this site's tools are built to refuse instead.