# \[req.\] Add to User-Settings: \`\[ \]\` Debug \`"payload"\` only
**URL:** https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215
**Category:** Core Development
**Created:** [7 June 2026 13:24 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215 "2026-06-07T13:24:44Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@PizzaProgram](https://discourse.nodered.org/u/PizzaProgram)
#### Post date: [7 June 2026 13:24 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/1 "2026-06-07T13:24:45Z")
Every each time I place a new Debug node to a flow,
1. I have to double click and
2. change from `"payload"` only -\> to Whole `msg`
3. Click Done
I thing even a beginner should rather see the whole msg, instead of just the `"payload"`.
Even more since `"topic"` was introduced.
I think it's time to change that policy. It does much more harm than good.
After all, it is a:
# Debug
node! Not some half-camouflage tool to show some very limited info.
## if accepted:
- It is very easy to double clock on the right palette, to show details, and
- teaching beginners about the whole `msg` structure from the first view.
- Also preventing possible errors
_(Last time it took me days to figure out what's going on, and wasted the time of many of You here at the forum too, because I've simply forgot to change that at **one** Debug node. This forum is full of similar topics.)_
But to calm everyone, who thinks that "payload only" behaviour by default is good,
I recommend to add a checkbox to the **User-Settings** , under " **Nodes**" section:
- `[]` Debug `"payload"` only by default _(default unchecked)_
To code devs:
- Please backport it to NR 4.x version too !
---
### Author:  [@E1cid](https://discourse.nodered.org/u/E1cid)
#### Post date: [7 June 2026 14:07 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/2 "2026-06-07T14:07:32Z")
I believe this was originally set to payload, as each debug adds overheads and each complete message adds greater overload.
I agree there is a need to inform new users that there could be more msg properties other than payload and topic.
One possible suggestion, a flag on the debug node (default payload) when extra properties available ( hover for message and possibly clickable to access the config).
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [7 June 2026 15:04 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/3 "2026-06-07T15:04:38Z")
This PR was already merged into v5 - [Allow a nodes defaults to be overridden by settings.js file by dceejay · Pull Request #5591 · node-red/node-red · GitHub](https://github.com/node-red/node-red/pull/5591) that allows you to set the defaults for that and many more nodes if required.
---
### Author:  [@bakman2](https://discourse.nodered.org/u/bakman2)
#### Post date: [8 June 2026 04:51 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/4 "2026-06-08T04:51:49Z")
What is the reason this cannot be controlled via the editor instead ?
It may be a bit of a stretch but has it been considered to do an overhaul of 'hiding' everything in settings.js, it has become an obscure and messy file to deal with, plus it is not exactly a 'modern' way. I understand that certain things are handled with at startup.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [8 June 2026 06:49 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/5 "2026-06-08T06:49:37Z")
> [@bakman2](#):
>
> What is the reason this cannot be controlled via the editor instead ?
I created the concept of ["alias nodes"](https://discourse.nodered.org/t/alias-nodes-redefine-default-settings-as-new-nodes/98137) as a method of setting alternative default values but that got no traction. That's a editor-only solution to having nodes with different default values. It's a non-standard and liable to break solution but it does the job _now_ for v4.x (and 3.x also).
A debug node that uses complete message as default is included in this [flow](https://flowhub.org/f/326616b4e24eab2a).
---
### Author:  [@knolleary](https://discourse.nodered.org/u/knolleary)
#### Post date: [8 June 2026 08:28 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/6 "2026-06-08T08:28:11Z")
> [@bakman2](#):
>
> What is the reason this cannot be controlled via the editor instead ?
Because of time and effort needed to design the UX and implement it. I had a full plate with other work and Dave stepped up to implement the basis of a solution via the settings file.
---
### Author:  [@hazymat](https://discourse.nodered.org/u/hazymat)
#### Post date: [11 June 2026 21:55 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/7 "2026-06-11T21:55:43Z")
Please may I add my two pence worth here?
I opened up User Settings today (after upgrading to 5.0) and was so impressed by how FEW settings there were.
> [@bakman2](#):
>
> plus it is not exactly a 'modern' way
User Settings page is clean, purposeful, and doesn't look like those old Windows applications designed by tinkerers with 20 tabs on a settings dialog box and hundreds of tick boxes to gaze aimlessly at while you forget what setting you were even looking for in the first place.
So on the contrary, I don't think it's "modern" at all to stack a whole load of settings upon settings into a UI.
> [@bakman2](#):
>
> it has become an obscure and messy file to deal with
May I ask how exactly you find it messy and obscure? I'm genuinely interested to hear the answer.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [11 June 2026 22:08 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/8 "2026-06-11T22:08:33Z")
> [@hazymat](#):
>
> May I ask how exactly you find it messy and obscure?
To be fair, there is some truth in this I believe. I've spent quite a bit of time over the years trying to make sense of the file and some time back made some suggestions for improvements to the comments that are built in, some of which were accepted.
My own versions of the file are still somewhat different to the default and I believe there are still possible improvements that could be adopted.
There _is_ an awful lot of "stuff" packed into that file! 😃 To find the right setting can take some searching. It actually surprises me that nobody has written a UI for managing it. After all, this is not that uncommon in the UNIX-like communities, a settings file with a UI helper app.
Having said all that, I do still like that it is a single file and I like that Node-RED has a lot of flexibility. Also, the file makes it easier to embed Node-RED into other apps and services. So overall, I think it is the write tool for the job. But for sure a utility to manage its entries would likely be welcomed by many people.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [11 June 2026 22:23 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/9 "2026-06-11T22:23:32Z")
One of the issues re automation is that it is a .js file. JSON would be a lot easier to automate and keep syntactically correct, but doesn’t support comments, which are kind of essential unless it is fully automated, at which point it may as well be in the editor. Also .js does allow extra capabilities that people do make use of so we want to stick with it for now at least, so it would need to be a tool that can handle the vagaries of js, and of course someone needs to actually write and maintain it as the settings evolve.
Of course things like Claude, etc may be able to help you fix things up as well.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [11 June 2026 22:28 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/10 "2026-06-11T22:28:15Z")
> [@dceejay](#):
>
> a .js file. JSON would be a lot easier to automate
Well, most of the file IS a JavaScript object. 😃 So it wouldn't be hard to move the core of it to a JSON file. The trick would be to retain a js file as an entry-point to Node-RED.
Right now, it is perfectly possible to load the settings themselves from a JSON file. Indeed, this approach would give a number of potential advantages in exchange for having an additional file to manage. Even that might be optional with the right load process.
The comments could all be moved to a structured documentation page/file.
Something to think about for v6 maybe?
---
### Author:  [@bakman2](https://discourse.nodered.org/u/bakman2)
#### Post date: [12 June 2026 02:14 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/11 "2026-06-12T02:14:01Z")
User settings vs settings.js.
I am referring to the settings.js file. The interface itself is fine and i was actually promoting to use it. Certain settings you should be able to control via the interface, especially when it controls interface outputs
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [11 August 2026 02:15 UTC](https://discourse.nodered.org/t/req-add-to-user-settings-debug-payload-only/101215/12 "2026-08-11T02:15:02Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.