Skip to content

AI Output Formatter

Recover usable JSON from a model's reply — strips fences, repairs trailing commas and smart quotes, and lists every repair it made.

The model's reply, exactly as it came back

208 B

Recovered JSON

134 B
{
  "name": "Ada Lovelace",
  "role": "Engineer",
  "active": true,
  "score": null,
  "tags": [
    "analysis",
    "compilers"
  ]
}

Repairs

7 applied
  • Unwrapped code fence1

    The response was wrapped in a Markdown code fence.

  • Replaced smart quotes2

    Curly quotation marks are not JSON string delimiters.

  • Converted single-quoted strings3

    JSON requires double quotes; single-quoted strings were converted.

  • Quoted bare keys5

    Object keys must be quoted strings in JSON.

  • Converted Python literals1

    True/False/None are Python, not JSON.

  • Replaced non-JSON numbers1

    NaN, Infinity and undefined have no JSON representation; replaced with null.

  • Removed trailing commas2

    A comma before a closing bracket is valid JavaScript and invalid JSON.

Every change is listed above. A document that already parses is never rewritten, and a truncated one is reported rather than closed.

Repaired in your browser — the response is never uploaded. To stop the problem at source, give the model a schema with the Structured Output Schema Builder; to explore the recovered object, use the JSON Formatter.

About the AI Output Formatter

This AI output formatter recovers usable JSON from what a model actually returned. You asked for JSON and got a sentence of preamble, a code fence, a trailing comma, and quotation marks that came out of a training corpus full of prose. Every one of those is a parse failure, none of them is a mistake in your prompt, and all of them are mechanically repairable.

Every repair is listed. The tool never hands back a quietly corrected document — each change is named, counted and explained, so you can see that a smart quote was rewritten rather than wondering why the output differs from what the model produced. That matters more here than in most tools, because the input is data you did not write and cannot eyeball.

A document that already parses is never touched. The parser runs first; repairs only happen after it has failed, so valid JSON comes back formatted and otherwise identical.

The one thing it refuses to do is repair a truncated response. A reply cut off by max_tokens is the most common unrecoverable case, and closing the brackets would produce a valid object that is silently missing data — which is worse than a parse error, because nothing downstream would notice. It is detected and named instead.

Finding the JSON is string-aware. Model output describing JSON usually contains braces in prose, so scanning from the first { to the last } gets it wrong on exactly the documents people paste here.

  • Strips Markdown code fences and the preamble and sign-off around them
  • Repairs trailing commas, smart quotes, single-quoted strings, bare keys, Python True/False/None, NaN and Infinity
  • Every repair named, counted and explained — nothing is fixed silently
  • String-aware extraction, so braces inside strings and prose do not confuse it
  • Truncated responses detected and reported rather than closed
  • Precise line and column on unrepairable input, via the same scanner as the JSON formatter
  • A prose mode for replies that were never meant to be JSON

How to use it

  1. Paste the model's reply exactly as it came back — fences, preamble, apology and all. Cleaning it first defeats the point.
  2. Read the repairs panel. It tells you what was wrong with the output, which is often more useful than the fixed JSON.
  3. Copy the recovered object, or switch the indent first.
  4. If it reports a truncation, do not work around it — raise max_tokens and re-run the request. The data is genuinely not there.
  5. Switch to Tidy prose for replies that are Markdown or plain text rather than JSON.
  6. Turn Repair off to see whether the raw extraction parses on its own.

Real-world use cases

Backend & API developers

Recover a parseable object from an LLM call that returns JSON wrapped in a code fence and preamble, without writing a one-off regex every time the wrapping changes shape.

AI & LLM application engineers

Debug a parser that intermittently throws on model output — paste the raw reply here to see exactly which repairs were applied and whether the response was genuinely truncated rather than just malformed.

QA & eval engineers

Triage a batch of failed responses from a model eval run, separating the ones that are mechanically fixable formatting from the ones that are genuine truncations needing a re-run.

Data & pipeline engineers

Clean LLM output in an ingestion pipeline — switch to Tidy prose mode for replies that were meant to be Markdown or plain text rather than JSON, without touching the wording.

Support & on-call engineers

Investigate a customer-reported parsing bug by pasting the logged raw model output and seeing immediately whether the cause is a fence, a trailing comma, or an unrecoverable truncation.

Examples

The usual reply

Input
Sure! Here's the JSON:
```json
{"a": 1,}
```
Let me know if you need changes!
Output
{
  "a": 1
}

Three repairs: fence unwrapped, preamble dropped, trailing comma removed. All three are listed with the text that was removed.

Python literals in a JSON response

Input
{"active": True, "note": None, "score": NaN}
Output
{
  "active": true,
  "note": null,
  "score": null
}

True/False/None come from Python-heavy training data. NaN has no JSON representation at all, so it becomes null — and that repair is reported, because it loses information.

Single quotes with an apostrophe inside

Input
{'note': 'it\'s fine'}
Output
{
  "note": "it's fine"
}

A global find-and-replace mangles this case. The conversion walks the string tracking which delimiter is open, so escaped quotes survive.

A truncated response is not repaired

Input
{"items": [{"id": 1}, {"id": 2
Output
The response is truncated — brackets are left open at the end of the input.

Closing the brackets would give you a valid object missing an unknown amount of data. Raising max_tokens is the only real fix.

Common errors

MessageCauseFix
No JSON object or array found in the responseThe model answered in prose — often a refusal, or an explanation instead of the data.Read the reply. This usually means the request failed for a reason worth knowing, not that the formatting broke.
The response is truncatedThe reply hit max_tokens mid-object.Raise max_tokens and re-run. If the output is genuinely large, ask for it in pages — a truncated response cannot be recovered from, only re-requested.
Unexpected token in JSON at position NThe error your own JSON.parse gave you before you came here.Paste the raw reply. This reports the position via a scanner rather than the platform message, so it gives a line and column even where V8 and Safari give none.
The repaired JSON is missing a field the model clearly returnedAlmost always truncation that stopped inside a later object, so the balanced value ended early.Check the character count against what you expected. If the input ends mid-word, it was cut off in transit.
This keeps happening on every requestPrompt instructions are a request, not a guarantee. "Return only JSON" is followed most of the time, which is not the same as always.Use structured outputs with a strict schema — then the shape is enforced by the API rather than asked for. The schema builder on this site checks one.

Frequently asked questions

›Does my model output get sent anywhere?

No. Everything runs in your browser. This matters more here than on most pages, because a model's reply frequently contains the customer data, source code or documents that were in the prompt.

›Why will it not fix a truncated response?

Because the fix would be a lie. Closing the open brackets produces JSON that parses, and it is silently missing however much the model had not written yet — so nothing downstream errors, and the missing data is discovered much later. A parse failure you must act on is the better outcome.

›Is it safe to run on valid JSON?

Yes. The parser runs before any repair, and a document that parses is returned formatted and otherwise unchanged. No repair can fire on input that was already valid.

›Why does it list the repairs instead of just fixing them?

Because the repairs tell you what is wrong with your pipeline. Smart quotes every time means the model is being asked for prose-shaped output; NaN means a numeric field is producing values JSON cannot represent. The fixed document solves today's problem, the list solves next week's.

›What happens to NaN and Infinity?

They become null, and the repair is reported. JSON has no representation for either, so there is no lossless option — but silently turning a NaN into null and saying nothing would hide a real numeric bug in whatever produced it.

›How do I stop needing this tool?

Use structured outputs. A strict JSON Schema on response_format makes the shape a guarantee rather than an instruction, and the model cannot emit a fence or a preamble around it. This tool is for the cases where that is not available — older models, other providers, or streamed output.

›Can it handle multiple JSON objects in one reply?

It recovers the first complete value. A reply containing several separate objects is usually a sign the prompt asked for a list without saying so — ask for a single array instead, which is also easier to consume.

›Does the code fence need to say ```json?

No. ```json, ```jsonc, ```javascript and ```js are all recognised, the match is case-insensitive, and a bare ``` fence with no language tag works too. Models are inconsistent about the tag, so it is not required for the fence to be unwrapped.

Last updated