The Set node (Edit Fields) in n8n: transforming your data without writing code

Between two applications connected by n8n, data rarely arrives in the right shape: a CRM returns first_name while your emailing tool expects firstname; an API delivers a price as a string where your database requires a number; a webhook dumps forty fields of which you only use five. The Set node — renamed Edit Fields (Set) in recent versions of n8n — is the building block designed for exactly this plumbing work: renaming, creating, removing and typing fields, item by item, without writing a single line of code. It's probably the transformation node you'll drop onto your canvas most often, right before the Merge node to combine sources or the IF node to route on a condition.

Two modes: Manual Mapping and JSON output

The Set node offers two ways to define its output, selectable in the Mode parameter:

• Manual Mapping — you build the output field by field in the interface: for each row, a field name, a type and a value. The value can be fixed ("Paris") or dynamic via an expression. It's the most readable mode, the one that best documents the transformation for whoever inherits the workflow.
• JSON — you write the complete output JSON object directly, with expressions inserted where needed:

{
  "firstname": "{{ $json.first_name }}",
  "email": "{{ $json.email.toLowerCase() }}",
  "source": "webhook-site"
}

JSON mode is faster when the target structure is deep or already known, and handy for pasting in an existing template. In return, it doesn't benefit from Manual Mapping's explicit per-field typing: whatever comes out of an expression keeps the type the expression returns.

This choice between visual construction and direct writing is no small detail. A study by Kandel, Paepcke, Hellerstein and Heer presented at the CHI conference in 2011 ("Wrangler: Interactive Visual Specification of Data Transformation Scripts" — see on Google Scholar) showed that a visual interface for specifying data transformations sharply reduces the time needed compared to writing equivalent scripts by hand. That's exactly Manual Mapping's bet: most everyday transformations are specified faster by clicking than by coding.

Manual Mapping in practice: drag & drop and expressions

In Manual Mapping mode, the node's left panel shows the input data (Schema, Table or JSON views). The most efficient move is drag & drop: drag a field from the input panel into an output field's value area, and n8n generates the matching expression automatically — {{ $json.first_name }} for instance. You can then enrich it by hand:

• {{ $json.first_name.trim() }} — strip stray whitespace;
• {{ $json.first_name + ' ' + $json.last_name }} — concatenate two fields into one;
• {{ $json.price ?? 0 }} — provide a default value when the field is missing or null;
• {{ $now.toISO() }} — timestamp the item as it passes through.

Everything n8n expressions allow is usable here: JavaScript methods on strings and numbers, the $json, $now and $itemIndex variables, data from an earlier node via $('Node name'). To go deeper into that syntax, our guide to JavaScript expressions in n8n covers the advanced cases.

Typing fields: string, number, boolean, array, object

Every field defined in Manual Mapping carries a type: String, Number, Boolean, Array or Object. This isn't decorative — the node converts the value to the requested type whenever possible. A "42" received as a string becomes the number 42 if the field is typed Number; a "true" becomes the boolean true.

This typing prevents a whole family of silent downstream bugs: an IF node comparing "10" > 9 as strings won't do what you expect, an API that requires an integer will reject the string, and an export to Excel or CSV will misalign its columns if types vary from one item to the next. Make it a reflex to type explicitly in the Set node, at the workflow's entry point: everything downstream becomes predictable.

If the conversion is impossible (typing "abc" as a Number), the node raises an error — a behavior you can adjust in the node's options if you'd rather skip failed conversions than interrupt the execution.

Dot notation: handling nested objects without code

To create or modify a field inside a nested object, there's no need to rebuild the whole object: dot notation in the field name is enough. Naming an output field user.address.city with the value Paris automatically creates the user and address objects if they don't exist, then places the value inside:

{
  "user": {
    "address": {
      "city": "Paris"
    }
  }
}

The same notation works for reading in expressions — {{ $json.user.address.city }} — and for arrays with an index: {{ $json.items[0].sku }}. To flatten a deeply nested webhook payload into a usable flat structure (the classic need right after a Webhook trigger), a few dot-notation fields beat a script hands down.

Include Other Input Fields: keep or drop the rest

By default, the Set node only passes through the fields you defined: everything else in the input item disappears from the output. That's intentional — the Set also acts as a filter, keeping only the essentials before sending data to an API or an AI model — but it's also the leading cause of "vanished fields" among beginners.

The Include Other Input Fields option flips that behavior: fields you didn't redefine are copied through unchanged alongside your own. Three variants are available: include all other fields, include only listed fields (Selected), or include everything except listed fields (All Except). That last variant is the simplest way to remove one or two sensitive fields (a token, a password) while keeping everything else intact.

When to prefer a Code node

The Set node works item by item: for each input item, it produces one transformed output item. As soon as the logic steps outside that frame, the Code node becomes the better fit:

• Aggregations across items — summing a field over all items, deduplicating, grouping: the Set only sees one item at a time.
• Variable-length arrays — transforming each element of an inner array calls for a loop, hence code (or a detour through Loop Over Items after splitting the array out).
• Rich conditional logic — one ternary expression in a Set stays readable; three nested ternaries no longer do.
• Deep restructuring — dynamically renaming keys, pivoting a structure, merging arbitrary objects.

In practice, clean workflows combine both: one or more Set nodes to normalize and type at the boundaries (right after a trigger, right before a send), and a Code node reserved for genuinely algorithmic transformations. Our article on expressions and the Code node helps you locate that boundary.

Common pitfalls

• Forgetting "Include Other Input Fields" and silently losing fields. The default behavior keeps only the fields you defined; when a downstream node looks for a "vanished" field, this is almost always where to look first.
• Leaving numbers as strings. An untyped price or quantity produces wrong comparisons and sorts further down the workflow, often without any visible error.
• Rebuilding a nested object by hand when dot notation in the field name (user.address.city) creates the intermediate levels automatically.
• Piling business logic into ever-longer ternary expressions instead of switching to a Code node or an IF node once the condition becomes structural.
• Using JSON mode with unescaped values. An input string containing a quote or a line break can break the generated JSON; in Manual Mapping the problem never arises, since each value is handled field by field.
• Chaining multiple Set nodes for a single normalization: one well-filled Set stays more readable and easier to maintain than four Sets in a row.

Going further

The Set node is the quiet workhorse of most serious workflows: in the AI Inbox Pack (€79), the email-triage workflows use it intensively to normalize the data extracted from messages (sender, subject, category, priority) before classification and routing — which is what guarantees every downstream node receives a stable, typed structure. To round out your data-manipulation toolkit, see how to combine multiple sources with the Merge node and how to generate Excel or CSV files from data freshly normalized by a Set.