n8n

n8n Set Node (Edit Fields) Explained: Shape and Clean Your Data (2025)

Rodrigo Ferreira

— 5 min read

The n8n Set node — renamed Edit Fields (Set) in recent versions — is the single most useful node for shaping and cleaning data inside a workflow. If you want to rename keys, add computed fields, drop everything you don't need, or turn a messy API or AI response into clean, structured output that the next node can trust, this is the node you reach for. This guide walks through every practical mode of the Set / Edit Fields node so you can normalize data with confidence.

What the Set (Edit Fields) node actually does

Every node in n8n passes items downstream as JSON. The Edit Fields node lets you rewrite that JSON: define the exact fields you want, set their values (statically or with expressions), and control whether the rest of the incoming data tags along. It does not call any external service — it is pure data transformation, which makes it fast, predictable, and safe to use liberally between other nodes.

You'll typically drop a Set node in three places: right after a trigger to define a clean starting object, right after an HTTP Request or database node to reshape a raw response, and right before a destination node (Sheets, CRM, email) to map your data into exactly the field names that destination expects.

Manual Mapping vs JSON mode

The node offers two modes. Manual Mapping gives you a row-by-row builder: you add a field, choose its type (String, Number, Boolean, Array, Object), name it, and assign a value. This is the readable, maintainable choice for most workflows — anyone opening the node sees exactly which fields exist.

JSON mode lets you write or paste a full JSON object (usually built from expressions) when you're constructing something dynamic or deeply nested that would be tedious to click out field by field. Start with Manual Mapping; reach for JSON only when the structure demands it.

The "Keep Only Set" option — why it matters

Below the field list sits a small toggle that changes everything: Include Other Input Fields (in older versions, the inverse "Keep Only Set"). This decides what happens to fields you did not explicitly define.

  • Include Other Input Fields ON: your defined fields are merged on top of the incoming item. Existing fields survive; you're adding or overwriting a few.
  • Include Other Input Fields OFF (keep only set): the output contains only the fields you defined. Everything else is dropped.

The "keep only set" behavior is your primary tool for cleaning data. When an API returns forty fields and you need six, define those six and turn off "include other input fields." The output is lean, predictable, and free of noise that could break downstream logic or leak into a spreadsheet.

Renaming keys

n8n has no dedicated "rename" action — you rename by defining a new field whose value points at the old one, then dropping the old one. Say an API returns customer_email but your CRM expects email. In an Edit Fields node, add a String field named email with the value:

{{ $json.customer_email }}

Then, with "include other input fields" off (or by simply not re-declaring customer_email), the old key disappears and only your clean email remains. Repeat for each key you want to standardize. This is how you normalize inconsistent naming — snake_case, camelCase, ALL_CAPS — into one convention before the data moves on.

Adding computed fields with expressions

Any field value can be an n8n expression, so Edit Fields doubles as a lightweight transformation engine. A few patterns you'll use constantly:

  • Concatenate: a full_name field set to {{ $json.first_name }} {{ $json.last_name }}.
  • Clean strings: trim and lowercase an email with {{ $json.email.trim().toLowerCase() }}.
  • Derive values: a status field set to {{ $json.amount > 100 ? "priority" : "standard" }}.
  • Add a timestamp: a processed_at field set to {{ $now.toISO() }}.
  • Type coercion: set the field type to Number and use {{ Number($json.price) }} to turn a numeric string into a real number.

Because the field type you pick (String, Number, Boolean, etc.) is enforced on output, Edit Fields is also where you fix types — a common source of downstream bugs when a node expects a number but receives "42".

Dot-notation for nested data

Real API responses are rarely flat. When data is nested, use dot-notation in expressions to reach into it. Given a response like { "user": { "contact": { "email": "a@b.com" } } }, pull the value with:

{{ $json.user.contact.email }}

You can also flatten nested structures for a spreadsheet or CRM by defining flat fields — email, phone, company — each pointing at its nested source. Arrays work the same way: {{ $json.items[0].sku }} grabs the first item's SKU. If the field name in the destination should itself be nested, you can name a field address.city and n8n will build the nested object in the output.

Cleaning messy extracted data is exactly the job the AI PDF Extractor (Invoice/Contract → Structured Data) template was built for — it turns raw PDF text into clean, named fields you can route anywhere. Get the AI PDF Extractor template →

Dropping fields you don't need

There are three ways to remove data with Edit Fields, depending on the situation:

  1. Keep only set: the cleanest approach — define what you want and turn off "include other input fields." Everything undefined is gone.
  2. Redefine a subset: when most fields should stay but you want to strip a few, keep "include other input fields" on and use a downstream node, or simply model your six wanted fields with keep-only-set.
  3. Set to empty: occasionally you want a key present but blank — define it as a String with an empty value.

Dropping fields early has real benefits: smaller payloads, faster execution, and no accidental exposure of sensitive fields (tokens, internal IDs, raw blobs) to logs or third-party destinations.

Normalizing messy API and AI output

This is where Edit Fields earns its keep. AI nodes and loosely-typed APIs return inconsistent shapes — sometimes a field is missing, sometimes it's nested, sometimes it's a string that should be a number. Place an Edit Fields node immediately after the source and impose a contract on the data:

  • Define every field your workflow depends on, with a fixed type.
  • Use expressions with fallbacks like {{ $json.total ?? 0 }} so missing values don't propagate as undefined.
  • Rename inconsistent keys to your convention.
  • Turn off "include other input fields" so nothing unexpected slips through.

The result is a predictable object shape that every downstream node can rely on — which means fewer broken executions and far less debugging. When an LLM extracts an invoice into free-form JSON, one Edit Fields node between the AI response and your database is the difference between clean records and constant firefighting.

Common mistakes to avoid

  • Forgetting the toggle: leaving "include other input fields" on when you meant to clean the object — you end up with your new fields plus all the old noise.
  • Wrong type: setting a numeric field as String, then wondering why math or comparisons downstream fail.
  • Overwriting silently: defining a field name that already exists overwrites it — usually what you want, but confirm you're not clobbering data you needed.
  • Expression on a missing path: referencing $json.user.email when user is sometimes absent throws an error; guard with ?. or ??.

Frequently Asked Questions

What is the difference between the Set node and Edit Fields?

They are the same node. n8n renamed the classic "Set" node to "Edit Fields (Set)" to make its purpose clearer. Older workflows and tutorials call it Set; newer versions label it Edit Fields. The functionality — defining, renaming, computing, and dropping fields — is identical.

How do I keep only the fields I define and drop everything else?

Turn off "Include Other Input Fields" (called "Keep Only Set" in older versions), which sits below the field list. With it off, the node outputs only the fields you explicitly defined and discards all other incoming data — the standard way to clean a bulky response down to what you need.

Can the Edit Fields node transform values, not just set them?

Yes. Every field value accepts n8n expressions, so you can concatenate strings, do math, coerce types, add timestamps, apply conditional logic, and read nested data with dot-notation. It works as a lightweight transformation node without needing a Code node.

Ready to automate?

Skip the manual mapping and start with a workflow that already turns raw documents into clean structured fields. Get this template on Gumroad →

Read more