Structured LLM Output: Output Parser

The Output Parser node in n8n enforces structured JSON output from LLM responses instead of relying on free-form text: it defines a schema that the language model must follow, and the Basic LLM Chain or the AI Agent then returns the result in exactly this format. For companies that want to forward LLM responses automatically into a CRM, ERP, or database, this is the difference between reliably parseable fields and tedious manual rework of text responses. As of: July 2026.

Why plain text fails in automations

Without further constraints, a language model returns answers in natural language. For a chat interface this is desired, but for a workflow step that is meant to feed the answer into a downstream system, it is a problem. Without a fixed structure, you have to work with text snippets, regex, or additional intermediate steps to extract individual values, and every small change in the model's wording can break this extraction. This is exactly where the Output Parser node comes in: it gives the model a schema and ensures that the response comes back as valid JSON with clearly named fields, ready to process directly in the following nodes.

The Structured Output Parser: enforcing a JSON schema

According to the n8n documentation on the Structured Output Parser the node returns fields based on a JSON schema and structures the LLM output accordingly. Two ways are available for defining the schema:

• Generate from JSON Example: You enter an example JSON, and the node automatically derives the schema from it. Only the object property types and names are used; the actual values in the example do not matter. In this mode, all fields are considered required.
• Define using JSON Schema: You create the schema manually. The documentation explicitly points out that references using $ref are not supported in this schema.

Important for practical use: sub-nodes such as this Output Parser process expressions differently from regular nodes. According to the documentation, with multiple input items an expression is always resolved only for the first item, not for each item individually. This can lead to unexpected results when batch-processing multiple records and should be tested beforehand.

Connecting to the Basic LLM Chain or AI Agent

For an Output Parser to take effect at all, the option "Require Specific Output Format" must be enabled in the corresponding root node, such as the Basic LLM Chain. Only then does the connection point appear where you can attach the Structured Output Parser, the Item List Output Parser, or the Auto-fixing Output Parser. For AI Agents, the documentation includes an explicit caveat: structured output parsing is often unreliable with agents. As an alternative, it is recommended to use a separate LLM chain that takes the raw data from the agent and only then converts it into the target format. For intermediate steps within an agent workflow, the documentation advises against using the parser anyway, and instead recommends describing the desired formatting directly in the system message. Anyone planning such agent workflows can find more on this under AI Agents.

Error handling: when the LLM does not return valid JSON

No language model is guaranteed to follow a given schema one hundred percent of the time; especially with more complex structures or long responses, it can happen that a field is missing, a quotation mark is placed incorrectly, or extra text surrounds the JSON. For exactly this case, there is a dedicated solution according to the n8n documentation on the Auto-fixing Output Parser: the node acts as a wrapper around an existing Output Parser. If the first parsing attempt fails, n8n automatically calls an additional LLM that corrects the faulty output and brings it back into the desired format. This significantly increases reliability but does not replace error handling within the workflow itself. To be on the safe side, you should still add a check after the parser, such as an error-trigger path or a condition that triggers if the correction attempt also fails. An automation that silently continues with empty or incorrect fields causes more damage than a cleanly logged error case.

Frequently asked questions about structured LLM output in n8n

What is the difference between the Structured Output Parser and the Auto-fixing Output Parser?

The Structured Output Parser defines the target schema and checks the response against it. The Auto-fixing Output Parser adds itself as an extra safety layer on top: it uses another parser, such as the Structured Output Parser, and calls an additional LLM if a parsing attempt fails, in order to correct the output.

Can I parse multiple items in a structured way at the same time?

Technically yes, in practice with a limitation. Since sub-nodes like the Output Parser only resolve expressions for the first input item, you should carefully test with multiple records whether the result looks as expected for every item, rather than blindly relying on batch processing.

Does the Output Parser guarantee one hundred percent valid JSON?

No. It considerably increases the likelihood of a structured, valid response, and the Auto-fixing Parser additionally catches many errors, but no language model gives a one hundred percent guarantee. A clean error path in the workflow therefore remains worthwhile.

Does the Output Parser also work reliably with AI Agents?

According to n8n documentation, it is less reliable than with a simple LLM chain. For agent workflows, it is recommended to either control the formatting via the system message or pass the raw response to a separate, downstream LLM chain with an Output Parser.