Home › Guides › JSON parse errors in n8n / Make automation runs
JSON parse errors in n8n / Make automation runs
Direct answer: the parse step is the messenger, not the culprit: some node upstream handed it text that is not strict JSON — a form-encoded webhook body, an HTML error page, an LLM answer wrapped in prose, JavaScript-flavoured values, or a payload truncated by a size limit. Copy the raw output of the node before the failure into the tool below; the Repair Report shows each defect at its location.
Inspect the raw payload from the failed node
Processed in your browser, so big pastes don't freeze the page. Nothing is uploaded — check your browser's network tab if you'd like to verify.
The usual suspects, in order
| Symptom in the raw output | Cause | Durable fix |
|---|---|---|
Starts with < | The HTTP step got an HTML page — wrong URL, auth redirect, or a 404/500 body | Check the URL and credentials; make the HTTP node fail on non-2xx instead of passing the body along |
| Prose + code fence around JSON | An LLM node answered conversationally | Use the platform's structured/JSON output option for that node, or extract before parsing; repair (above) for the runs already failed |
| Ends mid-string or mid-array | Output/token limit, or a field-size cap in a middle tool | Raise the limit or split the request; recover the prefix of failed runs with Truncated Recovery |
undefined, single quotes, trailing commas | A code/function node built "JSON" by hand or returned JS values | Return real objects and let the platform serialise; never template JSON as a string |
name=John&age=30 shape | The webhook/form body is URL-encoded, not JSON | Parse it as form data, or set the sender's content type to application/json |
| Many lines, one bad | An export in NDJSON/JSONL being parsed as one document | Process per line — NDJSON Salvage recovers the good records and quarantines the bad lines with their numbers |
A debugging habit that pays off
When a run fails, resist editing the workflow blind. Executions in both platforms keep the exact input each node received: copy the raw text feeding the parse step and inspect it outside the workflow first. Nine times out of ten the payload tells you which upstream assumption is wrong — and the Repair Report format (location + rule per defect) is designed to make that visible at a glance. Fix the assumption, then re-run the failed execution with the same payload to prove it.
Designing workflows that fail less
- Validate at the boundary: a parse/validation step right after any external input (webhook, HTTP, LLM) turns silent corruption into an early, located error.
- Keep payloads small: paginate API reads; ask LLMs for one record per call when the shape matters.
- Never build JSON by string templating in code nodes — construct objects and let the runtime serialise them.
- Treat repairs as telemetry: if you add a repair step for a third-party feed, log what it changed; a change in the repair pattern is your early warning that the feed's format moved.
Frequently asked questions
Why does my n8n / Make workflow fail with a JSON parse error?
The node received text that is not strict JSON. Frequent sources: a webhook body that is form-encoded or plain text rather than JSON; an HTTP node returning an HTML error page; an LLM node answering with prose and fences around the JSON; a previous node outputting JavaScript-flavoured values (undefined, single-quoted strings); or a long response truncated by a size limit somewhere in the chain.
How do I find the bad payload?
Open the failed execution, find the node before the parse step, and copy its raw output exactly — not the pretty-printed preview, which can hide the problem. Paste that raw text into the tool on this page: the Repair Report shows every defect at its location, which tells you which upstream node shape to fix.
Is it safe to just repair inside the workflow?
As a diagnostic, yes; as a permanent design, be deliberate. Repairing at the boundary is reasonable for LLM output and third-party exports you do not control — with the changes logged. For your own nodes, fix the producer: a silent repair layer can hide a drifting upstream format until it changes meaning, not just syntax.