Conditional routing splits a workflow into separate paths based on
data‑driven rules, and n8n provides two core nodes for this: the
IF node for binary true/false decisions, and the
Switch node for multi‑way routing with three or more
outputs. The IF node evaluates conditions with 10 comparison operators
across five data types, combined with AND/OR logic. The Switch node
operates in two modes—Rules (visual builder) and Expression (code‑based)—
supporting unlimited output branches with a fallback output for unmatched
items [1]
[2].

How does the n8n IF node create a true/false branching path?

The IF node evaluates a single condition or a set of conditions
combined with AND/OR logic against each incoming data item, then
routes it to the true branch if all conditions
match, or to the false branch otherwise. It
provides 10 comparison operators—equals, not equals, greater than,
less than, greater/less than or equal to, contains, not contains,
is empty, is not empty—across five data types.
[1]

The IF node’s “Combine” field controls whether multiple conditions
are joined with AND (all must match) or OR (any must match) logic.
Each branch can connect to any number of subsequent nodes, enabling
different processing chains for matched and unmatched items. A
straightforward example: check if an invoice total exceeds $1,000;
route high‑value invoices to a manager approval flow and low‑value
ones directly to payment processing. For real‑world customer routing
by country and name, the n8n blog’s country‑based routing tutorial
provides a complete walkthrough [3].
To pair the IF node with data recombination downstream, see the
core nodes guide with Merge node patterns.

What conditions, operators, and expression patterns can you use in an n8n IF node?

The IF node supports seven data types for comparison: String
(equals, contains, regex, isEmpty), Number (equals, greater,
less, range), Date & Time (is after, is before), Boolean
(is true, is false), and Array/Object (exists, isEmpty,
contains). The left operand pulls from a field, an expression like
{{ $json.price }}, or a static value.
[3]

Advanced patterns combine expressions and functions: for instance,
{{ $json.tags.includes("urgent") ? 'high' : 'normal' }}
pre‑processes a field before the IF condition evaluates it. The
“Ignore Case” option (turned on by default) allows case‑insensitive
string comparison; turn it off to enforce exact letter case. A common
edge case arises when webhooks send empty or missing fields—the IF node
may not natively recognize these as empty; using
{{ $json.field || '' }} forces the value into an
empty string for reliable evaluation [4].
For conditional logic that spans multiple items or requires programmatic
transformation, combine IF with the
Code node transformation guide.

How does the Switch node route data to three or more branches based on multiple conditions?

The Switch node evaluates multiple conditions simultaneously and routes
each data item to exactly one matching output branch. You define routing
rules based on a single field or expression and choose from two modes:
Rules mode (visual dropdown‑based condition builder:
string, number, date, boolean, array, object comparisons) and
Expression mode (JavaScript expression returning the
output index programmatically).
[2]

In Rules mode, the node supports all five data types—String, Number,
Date & Time, Boolean, and Array/Object—each with their full set of
comparison operations (e.g., String supports equals, not equals,
contains, begins with, ends with, regex). For date routing, select
“Date & Time > is after” and supply a reference date; for numeric
ranges, chain conditions in ascending order (e.g., values 1-5 then 6-10
then 11-13) with “Send data to all matching outputs” disabled to route
each value into exactly one bucket [5].
A critical configuration option: Fallback Output offers
three choices—None (ignore unmatched items), Extra Output (send to a
separate fallback branch), or Output 0 (route to the first rule’s
output). For the complete taxonomy of available data type comparisons
per mode, see the official Switch node parameter documentation [6].
To understand when Switch becomes the better choice over chained IF
nodes, see the
trigger nodes guide for workflow activation patterns.

When should you use an IF node instead of a Switch node in n8n?

Use an IF node when the decision is strictly binary—
true or false—such as checking if a field is empty, comparing a single
threshold, or validating user permissions. An IF node with Combine set
to AND handles 10 comparison operators perfectly for small sets of
conditions, and its two output connectors make the workflow logic
immediately clear for yes/no decisions.
[3]

Switch to the Switch node when you have three or more
distinct outcomes that all branch from the same decision point—such as
routing support tickets by category (billing, technical, return), leads
by country (US, UK, CO, others), or orders by status (pending, shipped,
returned, cancelled). The quick rule of thumb: If you find yourself
stacking three or more IF nodes in sequence to simulate multi‑way
routing, a single Switch node with a fallback output will be more
readable and maintainable [7].
For complex systems with many independent binary choices, bitmasking—
assigning each option a power‑of‑2 value and routing on the summed
number—can replace long chains of IF/Switch nodes with a single Switch
node [8].
For more on designing clean, maintainable branching architectures, see
SplitInBatches loop and batch processing guide.

How do you implement range routing and bitmasking in the Switch node?

For range routing—categorizing numeric values into buckets—configure
Switch rules in ascending order (e.g., values < 5, then values <= 10,
then values <= 13) with “Send data to all matching outputs”
disabled. This sequential evaluation routes each value into
exactly one bucket: 1–4 go to the first output, 5–10 to the second,
11–13 to the third [5].

Bitmasking is an advanced technique that replaces tangled condition mazes
with a single number: assign each independent choice a power‑of‑2 value
(Drink Coffee = 1, Drink Tea = 2, Food Croissant = 4). Add the values
for the customer’s order; the sum is unique for every combination. A
single Switch node then routes Coffee (1), Tea (2), Coffee + Croissant
(5), or Everything (7) to the correct workflow branch. This scales from
three choices (3 possible combinations) to N choices (2^N combinations)
without adding nodes, and applies anywhere you have multiple independent
flags: user permissions, feature flags, survey responses, or game states
[8].
For implementing bitmasking programmatically before routing, pair it with
the Code node transformation guide.

How does n8n’s branch execution order and performance work with IF and Switch nodes?

In n8n v1.0+, branches from conditional nodes execute sequentially
from top to bottom on the canvas. When two branches sit at the
same height, the leftmost branch executes first. You can change this
order in the workflow settings. This matters when downstream nodes depend
on results from a prior branch—always place the branch that must complete
first above the dependent branch.
[9]

For performance, the Switch node checks each rule sequentially and stops
at the first match (when “Send data to all matching outputs” is off)—
arrange the most frequent matches first to minimize average evaluation
time. For more than 20 rules, consider using a Code node with a lookup
table to reduce node overhead. The “Split → Process → Merge” pattern
(branch with IF/Switch, process each path independently, then reunify
with a Merge node) is the canonical design for complex workflows; use
the Merge node’s Combine mode with Matching Fields for inner‑join‑style
recombination [6].
For full details on the Merge node and the five join types it supports,
see the
core nodes guide (HTTP Request, Set, IF, Merge & Code).