JSON Repair in Practice: From Error Position to Reliable Data

API logs, JavaScript object snippets, and hand-edited configuration files often look like JSON without being valid JSON. The goal of repair is not just to silence the parser. The goal is to produce data that can be verified, reproduced, and trusted without changing its business meaning.

1. Preserve the original input

Do not overwrite the only copy. Save the raw text, source, timestamp, and request ID before using any repair tool. Logs may contain tokens, email addresses, or internal URLs, so remove fields that are not needed for debugging. Keeping the original lets you compare every repair step and roll back if a change alters meaning.

2. Start with the first error

Common problems include single-quoted strings, missing commas between properties, Python-style True or None, and trailing commas after the last item. Parsers usually report the first position where they can no longer continue, so avoid fixing the whole document by instinct. Work in order: normalize quotes, add missing commas, convert booleans and null to standard lowercase JSON literals, then remove trailing commas.

You can paste a candidate into the JSON Repair Tool and send the output to the JSON Validator for an independent check.

3. Do not remove comments with a blind replace

// and block comments are JavaScript syntax, not JSON. But those characters may also appear inside strings, such as URLs. A reliable repair flow identifies string boundaries before removing real comments. If a comment contains business context, move it into documentation or an explicit field instead of silently deleting it.

4. Truncated data cannot be guessed safely

A network interruption may leave half an array or an unfinished field. A tool can add closing brackets, but it cannot know the missing IDs, records, or array items. Even if the result becomes syntactically valid, it may not be complete. Fetch the source again or mark the record as incomplete.

Human review is also required for duplicate keys, leading zeros, very large integers, date strings, NaN, and Infinity. Different parsers may keep different duplicate values, and identifiers above JavaScript safe integer range should usually be strings.

5. Validate in four layers

First, confirm the repaired text parses in both your browser and backend runtime. Second, verify structure: root type, required fields, and value types. Third, compare before and after with JSON Diff and pay special attention to amounts, permissions, statuses, and IDs. Fourth, add the broken sample to regression tests so the same failure does not return.

6. When automatic repair is not enough

Temporary debugging snippets are fine candidates for assisted repair. Payment data, permissions, medical records, audit logs, and database migrations should not be rewritten without confirmation. In high-risk workflows, tools should report the error position and suggested change, then wait for a human decision.

Summary

Reliable JSON repair follows a simple order: preserve the original, fix the first error, record the change, validate again, and check business meaning. Automated tools are useful for punctuation, quotes, comments, and standard literals, but they cannot replace judgment about missing data or contract rules.