JSON guide
How to Fix Invalid JSON
A practical checklist for finding and repairing invalid JSON before sending it to an API or importing it into a system.
Recommended first tool
Start with JSON Validator
Validate JSON syntax, repair common issues, format output and inspect data safely in your browser.
Open JSON ValidatorWhat this guide covers
- Start with the first parser error
- Know where invalid JSON comes from
- Repair, then validate the repair
- Use schema checks before reuse
Start with the first parser error
Invalid JSON usually has one first failure that causes the rest of the document to look broken. Run the payload through a strict JSON validator before editing by hand. The first error normally points to a missing comma, an unclosed quote, a trailing comma, an unescaped control character, or prose copied into the payload.
Do not start by formatting the file. Formatters need valid JSON before they can safely indent it. The safer order is diagnose the parse error, repair the syntax, validate again, and only then format or minify the output.
Know where invalid JSON comes from
Many broken payloads are not actually JSON. They are JavaScript object literals with single quotes, comments, unquoted keys, undefined values, or trailing commas. API logs can also include timestamps, request labels, or markdown fences around the payload.
LLM output is another common source. A model may explain the payload before or after the object, or it may use code fences and comments. Remove surrounding prose first, then repair only the data body.
Repair, then validate the repair
A repair tool can turn common JSON-like text into a candidate JSON document, but the result is still a candidate. Review the diff mentally: did quotes change, did arrays close in the expected place, and did any text become a string value by accident?
After repair, run strict validation again. If the payload is going into an API, schema validator, import tool, or production config, validate the shape as well as the syntax. Valid JSON can still have missing fields or the wrong types.
Use schema checks before reuse
Syntax validation only proves the document can be parsed. It does not prove that required fields exist, dates are in the expected format, enum values are allowed, or nested arrays have the right structure.
For repeated payloads, generate or write a JSON Schema and run the repaired document through the schema validator. That second check catches business-rule failures before the payload reaches the system that will reject it.
Example repair workflow
Paste `{name:"Ada", plan:"pro",}` into JSON Repair. The tool should produce a quoted-key, no-trailing-comma candidate. Copy the repaired output into JSON Validator, confirm it parses, then format it for review.
If the payload must include `email`, validate it against a schema that requires `email` before sending it downstream.
FAQ
Can a repaired JSON document still be wrong?
Yes. Repair only addresses syntax. You still need to review values and run schema validation when the downstream system expects required fields or specific types.
Should I minify invalid JSON before repairing it?
No. Minifiers require valid JSON. Repair and validate first, then minify only after the payload parses correctly.
Next workflow