Sort JSON keys
Sort your JSON keys and stop squinting at the tree
- json_input
- ui_widget
- json
JSON has no inherent ordering, but the JSON you actually look at on screen does - and if a config file or an API response comes back in a scrambled key order, reading it in the LF tree widget is a chore. LF_SortJSONKeys does the boring, useful thing: reorders an object's keys alphabetically, ascending or descending, so the structure is actually scannable. It's the tidy-up node you add at the end of a JSON branch before you display or save, and it's about as close to zero-surprise as a node gets.
The inputs are exactly three. json_input is the object to sort. ascending defaults to true; flip it and the order inverts, which is occasionally exactly what you want when the interesting keys start with a prefix or a number. And mutate_source (default false) is the one worth a second thought: off, the node sorts a copy and leaves your input object untouched; on, it sorts in place. The copy default is the safe choice for a reason - it means you can sort the same source multiple ways or keep the original order available downstream. In-place sorting is the memory optimization for big objects, but you're giving up the original ordering, which you usually can't get back.
Output is a single json object, the sorted version. It's flagged as an output node, so it's built to be the end of a data chain: load your JSON (LF_LoadLocalJSON), shuffle or sort it, then display or save it - the sort is the "make it presentable" step before anything human reads it.
The honest caveat is the same one that applies to all key-ordering nodes: since JSON semantics don't care about order, sorting only matters when something downstream actually does - a human reviewer, a display widget, a diff against a previous export, or a consumer that emits keys in insertion order and you want that order predictable. If your JSON is going straight into another machine, the sort is cosmetic. If it's going into a diff, a changelog, or a pair of human eyes, it's quietly essential.
Mechanically it's a straightforward key sort - no value comparison, no nested sorting, just top-level key order. If you need to sort within nested objects too, you'll be recursing with a few of these or doing it in code. For the common "make this response readable" case, it does the whole job in one node.
Install is the LF standard - ComfyUI Manager → "LF Nodes", or git clone https://github.com/lucafoscili/comfyui-lf into custom_nodes, then restart. No models, no deps. And the note that follows the whole pack: comfyui-lf is frozen in legacy mode (fully functional), with the maintained version in lucafoscili/lf-nodes.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| json_input | JSON | Input JSON object. | |
| ascending | BOOLEAN | true | Sort ascending (True) or descending (False). |
| mutate_source | BOOLEAN | false | Sorts the input JSON in place without creating a new dictionary as a copy. |
| ui_widgetopt | KUL_CODE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| json | JSON | — |