n8n Merge Node Explained:
How to Combine Workflow Branches Without Guessing

The n8n Merge node is one of those nodes that makes perfect sense right up until you use it.

You drop it in, connect two branches, run the workflow, and either nothing comes out, the output is weirdly doubled, the items are paired in the wrong order, or it just sits there waiting and you have no idea what it's waiting for.

You go back to the docs. The docs explain the settings. They do not explain why your workflow is broken. You try a different mode. Still weird. You search for help. You find a community thread where someone had the same problem, and the accepted answer is three years old and references a different version of n8n.

That is the Merge node experience for most people.

This post is not going to walk you through every setting and call it a tutorial. It's going to tell you what each mode is actually for, when to use Merge versus Aggregate (they are not the same thing, and mixing them up costs you an hour every time), and what usually breaks so you can stop guessing.

What the Merge node does: joins branches. What it refuses to do: tell you when one branch is empty.

At the most basic level: the Merge node takes inputs from multiple branches and brings them together into a single output stream.

That is it. Everything else is configuration around how it does that.

In n8n, when you split a workflow into parallel branches, one fetching from an API, one pulling from a database, one running some processing step. Those branches do not automatically rejoin. They run separately and output separately. If you want combined data downstream, you need something to merge them back.

That something is the Merge node.

What trips people up is that "combining data" is not one thing. You might want to stack all the items together. You might want to pair them by position. You might want to join them by a shared field like an email address or an ID. Each of those is a different merge mode, and picking the wrong one produces wrong output in ways that are not always obvious at first glance.

Three situations that call for Merge, plus the one that people keep getting wrong by using Aggregate instead

Before worrying about modes, let's make sure Merge is actually the right tool.

Parallel enrichment: you pull lead records from your CRM, but you also need company data from an external API. Both run in parallel. At the end, you want one record per lead that contains both the CRM data and the enrichment data. Merge job.

Multi-source stacking: you have two different form sources, a Typeform and a native form on your site. Both feeds need to land in the same Airtable table with the same structure. Merge can stack those streams before the write step.

Rejoining after split processing: you split a list of items to run different logic on each group (say, high-value vs. low-value leads), and now you need to bring the results back together before the downstream notification step. Merge rejoins them.

If your situation does not look like one of these three, there's a decent chance you actually need the Aggregate node instead. More on that below.

What each Merge mode actually does: Append stacks, Position pairs, Matching joins

Here is what each mode actually does.

Append

Append is the simplest one. Every item from Input 1, followed by every item from Input 2. No pairing. No matching. Just a pile.

Use it when you have two streams of similar data and you want all of it together regardless of how items relate to each other, stacking two lists of contacts, combining two batches of records before a write step.

What breaks: if you expected items to be matched or paired, they will not be. Item 3 from branch A has nothing to do with item 3 from branch B, they just happen to end up next to each other. If you care about item relationships, Append is the wrong mode.

Combine by position

This pairs items by their index. Item 1 from Input 1 gets merged with Item 1 from Input 2. Item 2 with Item 2. And so on.

Use it when you know both inputs will have the same number of items and the order is meaningful. For example: one branch formats names, another formats phone numbers from the same original list, and you want to put them back together in order.

What breaks: if the item counts do not match, the shorter list determines the output length and you lose data silently. n8n will not throw an error. It just stops pairing when it runs out of items on one side. This catches people off guard every time.

Also: if the order is not deterministic, one branch hits an API that returns records in varying order, position pairing produces garbage output without telling you it's garbage.

Combine by matching fields

This is the join you probably actually want when enriching data. It matches items from Input 1 with items from Input 2 based on a shared field value, like an email address, a user ID, or an order number.

Use it when you're enriching one dataset with another and they share a common identifier. Branch A has your contact records. Branch B has enriched company data. Both have email. Set the match field to email and each contact gets their company data attached.

What breaks: when the field values do not actually match. This sounds obvious until you discover that one branch returns company_id as a string and the other returns it as a number, or one has a trailing space, or the casing is different. The Merge node will silently drop items with no match. You will get fewer output items than you expected and wonder where they went.

All other modes

There are a few other modes (like All Possible Combinations and some passthrough options) that mostly exist for edge cases. All Possible Combinations creates a cartesian product: every item from Input 1 paired with every item from Input 2. If you have 50 items in each branch, you get 2,500 output items. This is almost never what you want by accident. If you are not trying to do combinatorial logic on purpose, avoid it.

Merge vs Aggregate: joining branches is not the same as collapsing item volume

This is the one that causes the most confusion, and the docs do not always make it obvious.

Short version: Merge joins data from separate branches or input streams, it combines sources. Aggregate takes many items and rolls them into fewer items (usually one), it collapses volume.

Concrete example of the mix-up: you have a workflow processing 50 customer records and you want to get them all into a single array to pass to an API that expects a list. There is only one input stream, you do not need Merge at all. You need Aggregate to collect all 50 items into one JSON array.

If you try to solve this with Merge, you will either get nothing because there is no second input, or you'll confuse yourself into adding a fake second branch that does nothing useful.

Merge is for joining branches. Aggregate is for reshaping item volume. Different tools, different jobs.

Why your Merge node isn't working: five causes in order of how often they show up

The most common reasons, in rough order of how often they appear.

One branch never executed. Merge waits for both inputs before producing output. If one branch hit an error, a condition that returned nothing, or a filter that dropped all items, that branch sends nothing. Merge keeps waiting. Your workflow stalls. Check each branch independently to confirm both are actually producing items.

Item counts are mismatched in Combine by Position mode. As noted above, shorter list wins. No error. Just silent data loss. Always verify branch outputs are the same length when using position mode.

Matching field values do not actually match. Type mismatches, casing differences, whitespace, and encoding issues all cause silent drops in Combine by Matching Fields mode. Use the Code node to normalize your field values before they hit the Merge node if the source data is inconsistent.

The workflow structure makes Merge logically impossible. Merge needs to receive data from two actual inputs. If your branches converge at an IF node and one path is empty, or if you have a loop that feeds back into itself, the merge logic may not behave the way you drew it in your head. n8n's execution model is left-to-right, and the visual graph can mislead you about what is actually happening.

You needed Aggregate, not Merge. Single input stream, many items, wanted them collapsed? Wrong tool.

The enrichment pattern: how Merge works when a form submission meets company data from an API

Here is a workflow pattern that comes up constantly and uses Merge cleanly.

Setup:

• Branch A: a Webhook node receives a form submission with email, name, and company_name
• Branch B: an HTTP Request node calls a company data API (like Clearbit or Hunter) using company_name as the lookup value
• Both branches feed into a Merge node
• Downstream: an Airtable or Google Sheets write with the combined record

Merge configuration: mode set to Combine by Matching Fields, match on company_name (or whatever identifier exists in both branches).

Result: each form submission gets merged with its enriched company record. One row per submission. The downstream write gets a full combined object.

What to watch for: normalize the match field in both branches before the Merge node (lowercase, trim whitespace). Use n8n expressions or a quick Code node pass. And if the enrichment API returns no data for a company, decide ahead of time whether to pass the submission through anyway or drop it, handle that with an IF node before the merge.

This pattern is boring in the best way. It works. Once it works, you reuse it. You stop rebuilding it every time you need to enrich data.

The actual takeaway

Merge is for joining branches. It does not collapse items, it combines sources.

Aggregate is for collapsing many items into fewer outputs. Single input stream, reshaping volume.

Most Merge pain comes from picking the wrong mode, position vs. matching fields, or feeding it a branch that silently produced zero items. Combine by Matching Fields is usually the right mode for enrichment workflows, but normalize your match fields before they arrive or you will lose records without knowing why.

The node stops feeling cursed the moment you understand that it is not smart. It does exactly what you configured, including silently dropping items when the configuration does not match the data.

Nine out of ten broken Merge nodes have nothing wrong with the Merge configuration. The branch upstream produced nothing. Check that first. Always check that first.