How to use expressions in n8n?

In n8n, you use expressions by typing {{ ... }} inside any field that shows the “gear” icon or the “Expression” toggle. An expression lets you pull values from previous nodes (like {{$json.email}}), combine them, or run small pieces of JavaScript. Expressions always run at execution time, not when you type them, and they read whatever data the previous node outputs. In practice, you use expressions whenever a value shouldn’t be hard‑coded — things like dynamic emails, IDs, URLs, or timestamps.

 

What an Expression Actually Is

 

An n8n expression is just a short piece of JavaScript wrapped in {{ }} that lives inside a field. When the workflow runs, n8n evaluates that JavaScript against the current item’s data. “Item” means the JSON object flowing from node to node.

Inside an expression, you can use:

• $json — the current item’s JSON (most common)
• $prevNode — access data from a specific previous node
• $node — info about a node’s execution
• $env — environment variables
• JavaScript functions — like Date(), String(), string methods, etc.

 

The Core Pattern You’ll Use 90% of the Time

 

The most common expression is pulling something from a previous node, usually the node right before:

{{$json.email}}

This means: “in this item, look inside the JSON, and return the value called email.”

If that field was nested, you just go deeper:

{{$json.user.profile.lastName}}

If you need the output of a specific node:

{{$prevNode["Get User"].json.id}}

 

Enable Expression Mode

 

You can type {{ }} in the field, or click the small “Expression” toggle. When enabled, the field becomes dynamic and n8n highlights it in purple.

Tip: If the expression is invalid, n8n will highlight an error right in the field. It won’t break your whole workflow — it just won’t evaluate during execution.

 

Real Production Examples

 

Building a dynamic name (after an API returns first and last name):

{{$json.firstName + " " + $json.lastName}}

Compose a dynamic Slack message:

{{"New user signed up: " + $json.email + " at " + new Date().toISOString()}}

Read an environment variable (great for API URLs or secrets):

{{$env.BASE_URL + "/api/v2/users"}}

Create a fallback when a field might be missing:

{{$json.username || "unknown-user"}}

 

How Expressions Flow Through Nodes

 

Every node runs per item. That means:

• If a previous node returns 5 items, your expression runs 5 times.
• $json always refers to the item currently being processed.
• Expressions do not modify the data; they only read from it.

So if you want to transform data, you usually use a Code node or Set node, not just an expression field.

 

Common Pitfalls (Real-World Advice)

 

• Forgetting the field is per-item — leads to unexpected values if your workflow has multiple items.
• Trying to run long or complex logic in an expression — for anything big, use a Code node instead.
• Using expressions in credentials — n8n does not support that (for security reasons).
• Expecting expressions to run at design time — they only run during execution.

One good test is to switch the field to expression mode and click the “value preview” icon (the little eye). n8n shows the actual value based on the last workflow run.

 

When to Choose Expression vs Code Node

 

Use an expression when the logic is short and tied to a specific field. Use a Code node when the logic grows beyond a few lines or you need loops, conditionals, or multi-field transformations. Expression fields should remain readable — that’s the real production rule.

 

Reliable Pattern for Long-Term Workflows

 

In production, expressions are best for:

• Dynamic URLs
• Lookup of IDs from previous nodes
• Timestamp generation
• Building messages or payloads
• Extracting nested fields

Anything heavy or anything that changes often should live in a Code node or a database, not inside long expressions. That keeps your workflow maintainable and error‑resistant.