{{ summaryTitle }}
{{ summaryDetail }}
{{ statusBadge }} {{ repairProfileLabel }} {{ changeCountLabel }} {{ rootTypeLabel }}
Use Conservative for small syntax cleanup, JavaScript object for pasted code, or LLM/log paste for wrapped and truncated responses.
Auto handles Markdown fences and text around the first object or array without sending the payload anywhere.
The repaired artifact is always strict JSON when parsing succeeds.
Paste a single payload from logs, docs, browser consoles, or model output. File loading stays local in this browser.
{{ sourceMetaLabel }}
{{ sourceActionHint }}
{{ boundedIndent }} spaces
Use 0 to 8 spaces; 2 is the review default.
spaces
Leave on for LLM/log paste; switch off when every comma must be manually reviewed.
{{ repairMissingCommasEnabled ? 'On' : 'Off' }}
Use this for truncated model output; turn it off when partial payloads should fail loudly.
{{ completeClosersEnabled ? 'On' : 'Off' }}
Helpful for copied docs, chat transcripts, and ticket systems that alter quotes.
{{ normalizeSmartQuotesEnabled ? 'On' : 'Off' }}
Use this when paths or regex snippets contain single backslashes inside strings.
{{ fixInvalidEscapesEnabled ? 'On' : 'Off' }}
{{ heading }} Copy
{{ row[heading] }}
{{ heading }} Copy
{{ row[heading] }}
Chart runtime is unavailable; use the Repair Ledger tab or CSV export for the same data.
Tags: Data Format, Devtools
Export to PDF Fullscreen
Customize
Advanced
:

Broken JSON usually comes from places where people copy structured data before it is ready for a strict parser. Logs add surrounding text, documentation adds comments, chat output wraps the payload in a code fence, browser consoles allow object-literal shortcuts, and rich-text systems can change quote marks.

Repairing that text means converting loose JSON-like input back into one valid JSON value. Strict JSON is intentionally small: strings use double quotes, object member names are strings, array and object items are separated by commas, comments are not part of the data, and only lowercase true, false, and null are valid literal names.

Loose JSON-like text repaired into strict JSON with a valid parse, repair ledger, and structure audit.

A repair result should be treated as a reviewed conversion, not as proof that the original data was intended correctly. A missing comma can be inferred at an obvious boundary, but an incorrect field value, wrong array order, or duplicate meaning inside a pasted business record still needs human review.

The safest handoff is a strict JSON artifact plus evidence about what changed. That evidence matters when the payload came from a model answer, a ticket comment, a console snippet, a configuration example, or a log line that may have been wrapped or truncated before it reached you.

How to Use This Tool:

Choose the repair tolerance before pasting data, then read the parse status and repair evidence before using the output.

  1. Set Repair profile. Use Common JSON fixes for normal paste cleanup, JSONC config cleanup for commented configuration text, JavaScript object literal for console-style object text, LLM or log paste for wrapped or truncated material, and Conservative syntax only when only trailing-comma cleanup should be attempted.
  2. Choose Input envelope. Auto detect wrappers handles Markdown fences and surrounding prose, Repair whole source keeps the full text as the repair target, Prefer Markdown code fence starts from the first fenced block when present, and Extract first JSON block takes the first object or array it can find.
  3. Pick Output artifact as Pretty JSON, Compact JSON, or Canonical sorted JSON. The sorted option recursively orders object keys for stable local diffs, but it is not a full canonical JSON standard.
  4. Paste into Broken JSON source, drop a supported text file onto the editor, use Browse JSON, or load Sample. Browser file loading rejects files larger than 1 MB.
  5. Open Advanced when review policy matters. Pretty indent accepts 0 to 8 spaces, and the toggles control missing comma hints, completed closers, smart quote normalization, and invalid escape repair.
  6. Read the summary before copying. Strict JSON valid means the final parse succeeded. Needs manual edit means the best repair attempt still failed, and the alert should point near the first syntax problem when a location can be mapped.
  7. Use Repair Ledger and Structure Audit to decide whether the repaired text is trustworthy enough for the next step. If a warning says the extracted block is truncated or an unsafe integer may have lost precision, check the original source before using the repaired JSON.

Interpreting Results:

Valid JSON means the final text parsed as one strict JSON value after the selected repair steps. It does not mean the payload satisfies an API schema, a product rule, or the author's intent.

Repair needs review means the text shown in Repaired JSON is still a best-effort repair. Fix the error shown in the alert, then rerun the repair. Treat the reported line and column as the first parser complaint, not as proof that every later problem has been identified.

  • Repair Ledger shows each repair stage, whether it ran, how many changes it made, and a short detail note.
  • Structure Audit shows the parsed root type, node count, object key count, array count, max depth, size delta, and unsafe integer count.
  • Repair Impact visualizes the repair stages that changed the text or affected parse status.
  • JSON gives a structured diagnostic summary of the selected settings, warnings, error state, ledger rows, audit rows, and chart rows.

The main false-confidence risk is a repair that makes text parseable while changing uncertainty into silence. Recheck Repair Ledger whenever missing commas, completed closers, loose literals, or extracted blocks were applied, because those changes can hide a bad copy, a truncated record, or an intended string value that should not have been converted.

Technical Details:

JSON syntax is narrow by design. A valid text is one serialized value, object member names are strings, arrays are comma-separated sequences, and numbers follow a decimal grammar that excludes NaN and Infinity. Comments, single-quoted strings, unquoted names, and trailing commas are common in human-edited or JavaScript-adjacent material, but they are not strict JSON.

Repair works by applying cautious text transformations, then requiring a final strict parse. The final parse is the gate that separates a useful repair from text that still needs manual editing. Some transformations are low-risk, such as removing a comma before } or ]. Others need closer review, especially inserted commas, completed closing characters, and conversion of non-JSON literal names.

Transformation Core:

Repair Family What Changes Review Point
Envelope extraction Markdown fences and surrounding prose can be skipped so the first JSON-looking object or array becomes the repair target. Confirm that the extracted block is the payload you intended, especially when the block was incomplete.
Comment and comma cleanup Line comments, block comments, and trailing commas are removed outside quoted strings. Useful for configuration examples, but comments are not part of the strict JSON value.
Quote repair Smart quotes can become plain quotes, closed single-quoted strings can become double-quoted strings, and unquoted object names can be wrapped as strings. Check names that contain unusual characters, because only JavaScript-style bare names are targeted.
Literal normalization True, False, None, undefined, NaN, and Infinity outside strings are converted to strict JSON values. NaN, Infinity, undefined, and None become null, so verify that losing the original distinction is acceptable.
Escape and closer repair Invalid backslashes inside strings can be escaped, and missing trailing quotes, braces, or brackets can be appended when the chosen profile allows it. Completed closers are helpful for truncated model output, but they cannot restore omitted fields or values.

Rule Core:

State Rule Result Signal
No source No non-whitespace text is available. The summary asks for JSON-like text and the output preview stays instructional.
Already strict The selected payload parses before repair. The ledger records an initial valid parse and formatting can proceed without repair changes.
Repair attempt Allowed repair families run only after the initial strict parse fails. Applied rows show which transformations changed the text and how many times.
Final parse failed The repaired text still cannot be parsed as strict JSON. The summary switches to Needs manual edit, and the alert contains the parser message.
Final parse valid The repaired text parses as one JSON value and is emitted in the chosen artifact format. The summary shows Strict JSON valid, root type, repair count, and structure metrics.

Sorted output should be read as a local repeatability aid. It recursively sorts object keys before stringifying the value, which makes small object edits easier to compare in a diff. It does not claim full JSON canonicalization for signatures, hashing, number formatting, Unicode normalization, or cross-runtime interoperability.

Output Evidence What It Means How to Use It
Root type The parsed JSON value is an object, array, string, number, boolean, null, or no parse. Check that the receiving system expects that root shape.
Node count The total number of values visited after parsing. Use it to spot unexpectedly tiny or inflated payloads after extraction.
Max depth The deepest object or array nesting reached during the structure walk. Watch for truncation or accidental nesting when depth differs from the source you expected.
Size delta The byte size changed from input text to repaired output. Large deltas deserve review when compacting, comment removal, or extraction changed the payload substantially.
Precision risk One or more parsed integers are outside the exact safe integer range used by common JavaScript number handling. Quote identifier-like numbers before handoff when every digit must survive exactly.

This is a transformation and rule-based repair task, not a numeric calculation. A formula would not explain the result better than the ordered repair rules, final strict parse, and structure audit tables.

Privacy Notes:

The repair work, file reading, parsing, structure audit, chart data, copying, and downloads run in the browser after the page has loaded. The repair workflow does not upload the pasted JSON or selected file contents.

  • Keep secrets, access tokens, customer records, unreleased API payloads, and production configuration out of screenshots and shared links.
  • Because the current page state can be preserved for restoration or sharing, remove sensitive text before copying the address bar or sending a saved state to someone else.
  • Copy and download actions create local artifacts. Handle those files according to the sensitivity of the data you repaired.

Worked Examples:

Log snippet with a fenced payload

A job log says Here is the payload, then includes a fenced block containing 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 ledger should show fence or block extraction, quote repair, trailing comma removal, literal normalization, and a final valid parse. Structure Audit should report root type object.

Commented configuration example

A configuration sample contains // local override and a trailing comma before the closing brace. Choose JSONC config cleanup. The repaired output removes the comment and trailing comma, then emits strict JSON. Check Repair Ledger so reviewers know that notes from the source were not part of the final data.

Truncated response from a model answer

A pasted array starts with [{"sku":"A1"},{"sku":"B2" and stops before the final brackets. LLM or log paste can append missing closing characters when Complete missing closers is on, but Repair Ledger will show that closers were added. Treat that as a prompt to compare against the original response because omitted items cannot be recovered.

Large numeric identifier

A payload such as {"invoice_id":9007199254740993} may parse and show Strict JSON valid, while Structure Audit reports a Precision risk. Use {"invoice_id":"9007199254740993"} when the value is an identifier rather than a number meant for arithmetic.

FAQ:

Does repaired JSON mean the original data was correct?

No. It means the selected repair steps produced text that could be parsed as strict JSON. Check Repair Ledger, warnings, and the receiving system's schema or business rules before using the result.

Can it repair JSONC or JSON5 files?

It can clean common JSONC and JavaScript-style paste issues such as comments, trailing commas, single-quoted strings, and unquoted object names. It should not be treated as a complete JSON5 parser because not every JSON5 number or string form is repaired.

Why did the page convert NaN or undefined to null?

Strict JSON has no NaN, Infinity, undefined, or Python-style None. The repair pass normalizes those loose literal names to null, so review the field before handoff.

Why am I still seeing a parse error?

The remaining text still violates strict JSON after the allowed repair steps. Use the alert's line and column, try a more tolerant Repair profile only when appropriate, or turn off a repair toggle if the automatic edit is hiding the real problem.

Is canonical sorted output safe for signatures?

No. Canonical sorted JSON is a stable local key-sorted output for review and diffs. Signature schemes need their own canonicalization rules, especially for numbers, Unicode, and escaping.

Do selected files leave the browser during repair?

Selected JSON, JSONC, JSON5, and text files are read into the browser editor and repaired there after the page loads. Review links, clipboard data, and downloaded files separately because they can still expose sensitive values.

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 used in configuration files, where comments help people but are not data values.
JSON5
A JSON-related syntax that allows some JavaScript-style conveniences not accepted by strict JSON.
Repair Ledger
The result table that records each repair stage, status, count, and detail note.
Structure Audit
The result table that summarizes the parsed root type, size, node counts, nesting depth, and precision risk.
Unsafe integer
A whole number outside the exact safe range used by common JavaScript number handling.

References: