JSON Formatter vs JSON Repair

TL;DR Decision Table

Four tools, four jobs. The right pick depends on whether the input is already valid RFC 8259 JSON and what you need from it:

Tool	Input must be valid?	What it does	When to use
Validate	—	Answers yes/no: is this strict JSON?	First step when you need confidence another parser will accept it
Format	Yes	Pretty-prints valid JSON with consistent indentation	Reviewing logs, API responses, fixtures, config — when the input parses but is hard to read
Repair	No	Converts almost-JSON (single quotes, unquoted keys, trailing commas, comments, Python literals) into strict JSON	When JSON.parse fails on copied/edited/LLM-produced text
Minify	Yes	Strips whitespace from valid JSON	Compact value for env vars, query parameters, or command-line examples

Two more tools fit the same shelf: Diff compares two valid (or repaired) documents and shows what changed; Viewer renders a parsed document as a collapsible tree without modifying it.

One Example, Four Treatments

A single messy input shows the difference. The blob below is almost-JSON — it has unquoted keys, single quotes, a trailing comma, and a comment:

{
  name: 'Ada',
  active: True,
  /* role */
  role: "admin",
}

Tool	Output
Validate	❌ rejects: Expected property name or '}' in JSON at position 1
Format	❌ rejects (same parse error — formatters parse first)
Repair	✅ → { "name": "Ada", "active": true, "role": "admin" } then formatted
Minify	❌ rejects (must be valid JSON first)

Only Repair can take this input at all. Validate/Format/Minify need the Repair output as their input.

Practical Workflow

For messy input that almost-parses, chain the tools in this order:

1. Repair the syntax — pasted into JSON Fix, it strips comments, fixes quotes, removes trailing commas, lowercases Python literals, in one pass in your browser.
2. Format the result with consistent indentation (the same tool does both — Repair always formats its output).
3. Validate with the strict JSON validator to confirm the repaired document conforms to RFC 8259 — auto-repair fixes common syntax mistakes; validation confirms nothing else is wrong.
4. Diff against a known-good example if the payload controls application behavior — the JSON Diff tool shows what changed structurally, not just textually.
5. Minify only when you need the compact form (env var, URL parameter, command-line argument).

For input that's already valid JSON, skip step 1 and start at step 2.

Risk of Automatic Repair

Repair tools fix syntax, not semantics. If a repair changes quotes, comments, or commas, the intent is unambiguous — there's exactly one correct fix for 'name' → "name". If the tool has to guess a missing bracket, a field name, or a value, review the output carefully before using it in production. The same logic applies to LLM-produced JSON (repair-llm-json-output guide) — auto-repair is safe for display and debugging; for inputs that change state, validate strictly or reject.

Validate vs Format — Why They're Different

This is the most common confusion. Both call JSON.parse internally, but they answer different questions:

• Validate stops at the first error and tells you where. The line and column matter.
• Format parses, then re-serializes with indentation. It throws on invalid input — but it doesn't help you find what's wrong; it just refuses.

For a broken file, run Validate first to get the error location, fix the source, then Format for readability. Trying to Format invalid JSON to find errors is the long way around.

Repair vs Reject — A Production Heuristic

For systems where the JSON drives a side effect (writing to a database, sending money, granting permissions):

• In dev: repair-and-log. Surface the original + the repair so engineers can fix the producer.
• In staging: repair-and-alert. Test the actual production behavior end-to-end, but page someone when repair is needed.
• In production: strict-parse-or-refuse. Never silently repair a payload that changes state.

The same heuristic appears in the LLM JSON repair guide — it's the same problem class.

See also

This guide explains the decision. The hub compares all five JSON review tools and shows the order to chain them.

Sources

• RFC 8259 — the JSON Data Interchange Format (the "valid JSON" reference)
• MDN — JSON.parse (the strict parser underlying Validate and Format)
• MDN — JSON.stringify (the underlying serializer for Format and Minify; the indent argument controls which mode)

Last reviewed June 2026.