JSON Repair Tool

Introduction:

Strict JSON is useful because it leaves very little room for interpretation. A receiving parser expects one value, quoted object names, comma-separated members, lowercase literals, and numbers that follow the JSON grammar. Text that looks obvious to a person can still fail when it contains a comment, a missing comma, a single-quoted string, a copied log prefix, or a final brace that never made it into the paste.

Most broken JSON comes from boundaries rather than from the data model itself. Configuration examples borrow comments from JSONC. Browser consoles and JavaScript snippets allow unquoted names. Python-shaped values such as None or True appear in tickets. Model output can wrap the payload in a Markdown fence or stop midway through an array. Repair starts by identifying which boundary introduced the looseness, because each source deserves a different level of tolerance.

Syntax repair

Changing text so it can be parsed as one strict JSON value, such as removing a trailing comma or quoting a bare object name.

Data correctness

Checking whether the repaired value still means what the author intended and matches the receiving schema or business rule.

Review evidence

A record of the changes and warnings that lets a reviewer decide whether the repair is safe to use.

Those distinctions matter because repair can make a payload valid without proving that it is complete. Adding a missing brace may let a truncated array parse. Turning undefined into null may be the only valid JSON choice, but it loses the difference between "not provided" and "intentionally empty." Large numeric identifiers can also parse as numbers while losing exact digits in common JavaScript number handling.

• Comments and trailing commas usually point to JSONC or documentation-style examples, not strict JSON.
• Single quotes and unquoted object names usually point to JavaScript object-literal habits.
• Capitalized booleans, None, NaN, and Infinity usually point to Python or JavaScript values that need a strict JSON replacement.
• Duplicate object names and very large integers can remain syntactically valid while still creating interoperability risk.

A repaired payload is best treated as a handoff candidate. It should parse cleanly, preserve the intended root shape, and leave enough evidence for someone else to see what changed before the value reaches an API, a configuration file, a ticket, or a production data import.

How to Use This Tool:

Start with the least tolerant repair profile that matches the source, then inspect the summary and review tabs before copying the repaired JSON.

1. Choose Repair profile. Use Conservative syntax only for trailing commas, JSONC config cleanup for comments, JavaScript object literal for pasted code objects, LLM or log paste for fenced or truncated text, and Common JSON fixes for mixed everyday cleanup.
2. Set Input envelope. Auto detect wrappers is the normal choice for prose plus a payload. Use Repair whole source when every character should be treated as data, Prefer Markdown code fence when a fenced block is the source of truth, or Extract first JSON block when a log line contains one object or array inside other text.
3. Pick Output artifact. Pretty JSON is easiest to review, Compact JSON is useful for paste targets that dislike whitespace, and Canonical sorted JSON recursively sorts object keys for stable local diffs.
4. Paste text into Broken JSON source, drag a JSON, JSONC, JSON5, or TXT file onto the editor, select Browse JSON, or load Sample. The browser rejects selected files larger than 1 MB, so paste a smaller excerpt when that warning appears.
5. Open Advanced when review policy is strict. Use Pretty indent from 0 to 8 spaces, and decide whether missing comma hints, completed closers, smart quote normalization, and invalid escape repair should run for this source.
6. Read the summary badges. Strict JSON valid means the final strict parse passed. Needs manual edit means the best repair attempt still fails, and the alert gives the first parser location the browser can report.
7. Before handoff, check Repair Ledger for changed stages and Structure Audit for root type, node count, nesting depth, duplicate keys, size delta, and precision risk. Use Repaired JSON only after those checks match the source you intended to repair.

Interpreting Results:

Strict JSON valid is a syntax result. It says the final text is one parseable JSON value after the selected repair steps. It does not prove that the value matches a schema, contains every expected field, avoids duplicate meaning, or represents the author's original intent.

Needs manual edit means automatic repair stopped short of valid JSON. The reported line and column identify the first parser complaint, not necessarily the only problem. Try a more tolerant Repair profile only when the source really came from logs, model output, or JavaScript-style text; otherwise fix the nearby text manually and rerun the repair.

• Repair Ledger is the change record. Pay close attention to inserted commas, completed closers, literal normalization, quote repair, and envelope extraction because those edits can change the meaning of ambiguous input.
• Structure Audit is the shape check. Compare the root type, object key count, array count, max depth, and size delta with what you expected from the original source.
• Precision risk warns about integer values outside the common exact JavaScript range. Quote identifier-like numbers when every digit matters.
• Duplicate keys warns that repeated object member names were seen before parsing. Many parsers keep only the last value, so check the original text before relying on the repaired object.
• Repair Impact is a quick visual summary of changed or failed stages, useful when you need to explain why a payload required review.

The main false-confidence risk is a valid output created from incomplete or ambiguous input. If the source came from a partial response, copied documentation, or a ticket comment, compare the repaired root shape and warnings against the original context before sending it downstream.

Technical Details:

JSON repair is a text transformation followed by a strict parse. The transformation stage handles common non-JSON conveniences, while the final parse enforces the JSON grammar: one serialized value, quoted string names in objects, comma-separated array and object members, decimal numbers without NaN or Infinity, and only lowercase true, false, and null as literal names.

Repair rules are ordered because earlier changes can make later ones possible. Extracting a fenced block removes prose that a parser cannot read. Normalizing smart quotes may make string repair possible. Removing comments and trailing commas reduces JSONC-style text to data-bearing tokens. The final parse remains the gate; if the repaired text still cannot be parsed, the output is treated as review material rather than finished JSON.

Transformation Core:

Profile Rules:

Strict Parse and Audit Rules:

Sorted output is a local review convenience. It recursively orders object keys before formatting so repeated repairs are easier to compare in a diff. It is not a full canonical JSON scheme for signatures, hashes, Unicode normalization, number formatting, or cross-runtime signing rules.

This is a rule-based transform rather than a numeric calculator. A formula block would not clarify the result as well as the transformation table, profile rules, strict parse gate, and audit signals.

Privacy Notes:

The repair pass, file reading, parsing, audit tables, chart data, copy actions, and downloads run in the browser after the page has loaded. Pasted JSON and selected file contents are not uploaded for repair.

• Keep secrets, access tokens, private customer data, unreleased configuration, and production payloads out of screenshots and shared links.
• Because the current state can be restored or shared, remove sensitive source text before copying the address bar or sending a saved state to someone else.
• Downloaded JSON, CSV, DOCX, and image files are local artifacts. Store or delete them according to the sensitivity of the repaired payload.

Worked Examples:

Fenced checkout payload from a job log

A log entry includes prose, then a fenced block with orderId: 'A1001', items: ['sku-1',], and active: True. With Repair profile set to LLM or log paste and Input envelope set to Auto detect wrappers, the summary should show Strict JSON valid. Repair Ledger should record fence or block extraction, quote repair, trailing comma removal, literal normalization, and final strict parse. Structure Audit should report root type object.

Commented local configuration

A config sample contains // local override, a Windows path with a single backslash inside a string, and a trailing comma before }. JSONC config cleanup with Escape repair on can remove the comment, fix the trailing comma, and escape invalid backslashes. Check Repaired JSON before copying because the comment is not preserved as data.

Identifier larger than the safe integer range

A payload such as {"invoice_id":9007199254740993} can parse as Strict JSON valid, while Structure Audit reports Precision risk greater than zero. If the value is an identifier, change it to a string such as {"invoice_id":"9007199254740993"} before handoff so digit-for-digit identity is preserved.

Duplicate member names in a copied object

A pasted object contains {"status":"draft","status":"paid"}. The repaired text may still be valid JSON, but Structure Audit should show Duplicate keys greater than zero. Compare the original source and remove the wrong member before relying on the parsed result, because many parsers keep only the last value.

Truncated model response

A response starts with [{"sku":"A1"},{"sku":"B2" and stops before the closing characters. LLM or log paste can append missing closers when Complete missing closers is on, but Repair Ledger will show that closers were added. Treat the result as a recovery draft, not proof that the omitted fields or array items were recovered.

FAQ:

Glossary:

Strict JSON

A JSON text that follows the standard syntax for objects, arrays, strings, numbers, booleans, and null.

JSONC

A JSON-with-comments style often used for configuration files, where comments help readers but are not part of the data value.

JSON5

A JSON-related syntax that allows several JavaScript-friendly conveniences that strict JSON does not accept.

Repair Ledger

The result table that records each repair stage, status, count, and detail note.

Structure Audit

The result table that summarizes root type, size change, parsed value counts, nesting depth, precision risk, and duplicate keys.

Unsafe integer

A whole number outside the common exact JavaScript integer range, where digit-for-digit precision may not survive parsing.

Duplicate keys

Repeated object member names in the same object, which can cause parsers to disagree or keep only one value.

References:

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, IETF/RFC Editor, December 2017.
• ECMA-404: The JSON Data Interchange Syntax, Ecma International, 2nd edition, December 2017.
• JSONC Specification, JSONC.org.
• JSON5 Summary of Features, JSON5.org.
• Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.