Renaming and Removing Message Fields in Node‑RED with the Change Node

The problem: cleaning up incoming data without writing code

Many Node‑RED flows start with a raw message — for example, an MQTT payload that contains extra metadata, nested objects, or field names that don’t match your downstream nodes. Manually stripping or renaming those fields in a Function node works, but it adds JavaScript boilerplate and makes the flow harder to read for teammates who prefer low‑code solutions.

Thesis: the Change node can handle most field‑level edits declaratively

The Change node lets you rename, add, or remove properties on the msg object using a simple rule set. It evaluates template expressions (like {{msg.topic}}) in the context of the incoming message, creates a new msg object, and leaves the original untouched — so you can safely chain it with other nodes.

Worked example: rename payload to data and drop unused fields

1. Drag a Change node onto the canvas.
2. Double‑click it to open the configuration.
3. In the Rules section add three entries:
   • Set data to msg.payload (this renames the field).
   • Delete msg.metadata (removes an unwanted top‑level property).
   • Change msg.location to the value of msg.payload.coords using the expression {{msg.payload.coords}}.
4. Connect an Inject node (set to emit a JSON object) to the Change node’s input, and a Debug node to its output.
5. Deploy the flow and click the inject button. Inspect the debug sidebar — you should see a msg object that now contains data, location, and no metadata field.

Note: the example does not claim any specific output; you can verify the result by observing the debug output after deployment.

Trade‑offs and limitations

• Expressions are synchronous: the Change node cannot perform asynchronous work (e.g., calling an external API). For async logic you must fall back to a Function node.
• Undefined references: if a template expression points to a property that does not exist, the result is undefined. Downstream nodes may treat this as a missing value, so consider adding a preceding Switch node to guard against missing fields.
• Performance on large payloads: renaming or deleting many fields in a huge object can add overhead. For bulk transformations (dozens of fields) a Function node with a loop may be more efficient.

When to reach for the Function node instead

Use the Change node when your manipulation is limited to reading, writing, or deleting static or dynamically computed field values. If you need to iterate over arrays, perform conditional logic that depends on multiple fields, or call asynchronous nodes, encapsulate that logic in a Function node to keep the flow maintainable.

Actionable closing

Next time you see a messy msg object, try adding a Change node first. Define the rename or delete rules, deploy, and verify with a debug node. If you hit the limits described above, refactor the problematic part into a Function node — but you’ll often find that the Change node handles the majority of everyday data‑cleaning tasks without a single line of JavaScript.