On this page
Save the original AI response before editing its JSON. If the document is inside a Markdown block, copy the contents and validate them first. You may not need to repair anything. If you do, compare the result with the original before using it: fixing the syntax cannot bring back missing data. You will need the source or a complete response for that.
What to do with the response you received
- Save a copy of the entire response so you can compare changes.
- If it contains one complete Markdown block, copy just the document inside. For mixed prose or multiple blocks, first identify which document belongs to your task.
- Validate the document. If its syntax is already correct, move on to checking the data; repair is optional.
- If repair is needed, open JSON Repair, paste the original into Input text, choose Repair JSON, and select Repair. Pasting or changing modes does not run the operation.
- Review the proposed output, warning, and changes. Compare values and fields with the complete original or the source.
- Once you have checked the changes and the data your application needs, select Copy output.
| What you received | First action | What to check |
|---|---|---|
| One complete Markdown block containing valid JSON | Copy just the JSON and validate it. | Only the wrapper was removed. |
| JSON with comments or trailing commas | Use JSONC to JSON; see the JSON and JSONC guide. | Those extensions are removed and values stay intact. |
| Other errors, such as single quotes or unquoted keys | Fix the error by hand if you know how, or try Repair JSON. | What the tool changed and whether it added any values. |
| A document cut off halfway through a value or record | Request the complete document or consult the source. | What content is missing; adding closing delimiters does not restore it. |
If you recognize the error and want to fix it by hand, see how to fix JSON syntax errors. When a response mixes explanations with several code blocks, first find the JSON you need. The repair tool cannot decide which document you meant to use.
A complete Markdown block: remove the wrapper
Here is the sample response, including its Markdown markers:
```json
{"order":"A-17","units":2,"delivered":false}
```Expected data after removing only the wrapper:
{"order":"A-17","units":2,"delivered":false}The JSON inside the block is already valid, so you can just copy it and validate it. In a test with the full response, Repair JSON removed the Markdown markers and left the line breaks around the document. The data came out as shown above.
Check that order keeps the string "A-17", units the number 2, and delivered the boolean false. Only the Markdown markers should disappear in this example. The report can group several edits together, so compare the contents too, rather than relying on the number of reported changes.
Choosing this mode displays “Repair is heuristic and may change meaning. Review every change.” This operation also reports: “The output was produced by heuristic repair. Check that its meaning is correct.” The mode warning remains visible even when valid input passes through unchanged.
A truncated document: an added value is not a recovered value
This response ends immediately after the colon:
{"order":"A-17","units":Result of testing this example in Repair JSON:
{"order":"A-17","units":null}The tool added null and a closing brace. The syntax is now valid, but we still do not know how many units there were: it could have been 2, 20, or another quantity. That null is not a recovered value. We also do not know whether the application accepts nulls in this field or whether more order details were cut off.
Ask for the complete response again, or look up the quantity in the original source and enter it in the field. The result above is specific to this example. A different cut may lead to different edits or a failed repair. The same problem applies to an unfinished string or array: adding the closing delimiter does not restore what was lost.
Does your application expect a string or a number?
Both documents have valid syntax:
{"units":"2"}{"units":2}The first contains a string and the second a number. RFC 8259 distinguishes these value types. If your application’s contract requires a number, the first document does not meet it. Check the source before correcting it: blindly converting types can change data, such as an identifier "002" whose zeros belong to the value.
The repair tool does not know your application’s rules: which fields are required, what types they accept, or how many records you asked for. You need to check those even if the JSON passes validation on the first try.
Review before using the output
- Were only wrappers removed, or were values, quotes, or closing delimiters added?
- Are the required fields and expected number of records still present?
- Were identifiers, numbers, booleans, and nulls preserved, with the types the destination requires?
- Are there warnings, such as possible precision loss in large or highly precise numbers? Check their original text and the representation your application will use.
- Can you justify every change using the complete document or the source?
If the tool reports success, the output has valid syntax; you still need to check any data it added. If it stops because of a processing limit, read the message to find out which limit was reached. That failure alone does not tell you whether the JSON has a syntax error or can be repaired.
Use the result once you have checked that the edits preserve the data and that your application can use it. If a value or type is wrong, correct it using the source. If information is missing and you have nowhere to check it, ask for the data again.
In your next request, ask for JSON only and specify the fields, their types, and the number of records you expect. That gives you something concrete to check when you review the response.