Your Structured Output Parser got text back from the model that either isn't valid JSON or doesn't match the schema you gave it — and if you built that schema with Generate from JSON Example, every field in your example is mandatory, so one missing key is enough to throw this.
Upgrading n8n will not fix it. This is thrown by design, and it's been reported across 1.88, 1.101, 1.107 and 1.112 on Claude, Gemini, GPT-4o and GPT-3.5 alike. The GitHub issue for it is closed as not planned.
The Structured Output Parser does three things in order, and the error message is identical whichever step fails. That's why the fixes people post in the forum contradict each other — they're fixing different bugs.
JSON.parse() whatever's leftSo before changing anything, read what the model actually sent. Two ways:
If it isn't JSON, you have Failure A. If it's JSON but a key is missing, spelled differently, or the wrong type, you have Failure B.
n8n's fence stripping is stricter than people expect. It walks the reply line by
line and only strips a fence when the opening line is exactly three backticks, or
three backticks followed by json, with nothing else on that line — and the closing
line is three backticks alone.
These all survive stripping and then blow up JSON.parse:
jsonjavascript or js instead of json{ on the same lineHere is the JSON you asked for: {"…"}Prose before the opening fence is fine, and so is prose after the closing fence. It's the fence line itself that has to be clean.
The fix is in the prompt, not the parser. Put this in the system message, as the last line so it isn't buried:
Respond with a single JSON object and nothing else. No markdown, no code fences, no explanation before or after.
If your model node has a response-format option that forces JSON, turn it on as well — that removes the failure at the source instead of asking the model nicely.
This is the common one, and it usually traces back to a single documented behaviour:
Generate from JSON Example treats every field in your example as required.
So if your example is
{ "company": "Acme", "amount": 1200, "note": "paid late" }
then the model must return note on every single item. On the run where there's
nothing to note, it omits the key, Zod rejects the object, and you get this error —
on item 40 of 50, which is why it looks intermittent.
Fix: switch Schema Type to Define using JSON Schema and write the schema
by hand, putting only the genuinely mandatory keys in required:
{
"type": "object",
"properties": {
"company": { "type": "string" },
"amount": { "type": "number" },
"note": { "type": "string" }
},
"required": ["company", "amount"]
}
Three more things that cause shape failures, in the order they're worth checking:
$ref is not supported. n8n documents this. A schema that factors out a
repeated sub-object with $ref will not work — inline it.enum. A model asked for "intent": "string" will eventually invent a
fifth category; a model asked for "intent" from an enum of four will not.If the message you actually got was "The AI model returned an empty response to the Structured Output Parser", that's a different error with a different cause: the model ran out of output tokens before it finished the object. Raise the model's max output tokens, shorten the prompt, or simplify the schema. Nothing above applies.
Several people in the main forum thread report the same prompt and the same schema working once they swap the AI Agent for a Basic LLM Chain. That isn't superstition. Under an Agent, the parser validates the agent's final answer, and an agent that has just run two tool calls has a strong habit of narrating what it did before answering. A chain has no tools and nothing to narrate.
If you don't need tool calling, use the chain. It's a smaller surface.
The Auto-fixing Output Parser wraps another output parser, and when the first one fails it calls out to another LLM to repair the output. It's worth adding — but be clear about what it can and can't do:
So: fix the schema first, then add auto-fixing as a seatbelt. Not the other way round.
An LLM produces tokens, not objects. The Structured Output Parser is a validator bolted onto the end of a process that has no native concept of a schema, so the schema is enforced after the fact by throwing. Every design decision follows from that — which is why the durable fix is always to shrink the gap between what you ask for and what the model can reliably produce, rather than to catch failures harder.
Concretely, the workflows that don't hit this error are the ones that ask for a flat object, with a short list of required keys, with fixed-value fields declared as enums, and a system message that forbids anything but JSON.
Treadle's Inquiry Triage applies the enum-and-validate discipline above to inbound email: Claude classifies the intent into one of six fixed values, and every extracted company name and figure must literally appear in the source message before it's accepted.
Sources: n8n's source for the Structured Output Parser; the n8n docs for the Structured Output Parser and Auto-fixing Output Parser; n8n-io/n8n issue #18765; community.n8n.io thread 106424. n8n's own documentation does not currently cover this error.
Last verified 15 September 2026 against n8n 2.39.5 (source read on master @ 2.40.0). n8n changes these messages between releases; if the wording you see differs, the version above is what this page was checked against.