n8n Expressions

n8n's expression language is JavaScript embedded in {{...}} blocks. They run synchronously, on a single item at a time ($json), with access to upstream nodes ($('Name')), Luxon for dates, and most of native JS.

Non-negotiable

Reference data by node name, not $json. Use $('Node Name').item.json.field (or .first().json.field). $json works but breaks when any node clears item context (Aggregate, Code with Run for All, branching merges) or a refactor adds an intermediate. Failures are silent, and downstream gets the wrong data with no error. Node-name references are stable.

Strong defaults

• No Set nodes whose only purpose is to feed a single downstream field. Inline the expression at the consumer. Set earns its place when 2+ consumers read the same derived value, the derivation is non-trivial, or the Set is a sub-workflow's final return-shaper. See "The Set-node antipattern" below.
• Luxon for dates, not the DateTime node. Date math, formatting, and parsing all work in expressions: {{ DateTime.now().minus({ days: 7 }).toISO() }}. The DateTime node is more visible on the canvas for beginner human users, but avoid it unless the user specifically asks for it.
• Expressions over extra nodes generally. Build the email body in the email node's body field, and compute the URL in the HTTP Request's URL field. Reach for an extra node when the transform is reused or the primary purpose of a section.
• Multi-line expressions are indented and commented. When an expression spans more than one line, format it like real code. Most n8n users are not coders, so explain the code with concise inline comments

Why reference by node name ($('Name').item.json.x) over $json.x

$json means "the current item flowing into this node." Fine when the node is directly downstream of one source and nothing has cleared the item context (some nodes do: Aggregate, Code with Run for All, branching merges).