Smart Dictionary from String 📝

ComfyUI is allergic to unstructured text, and that's the whole problem this node solves. LLM outputs come back as strings, config fields come back as strings, and someone's workflow tells you to type "width: 1024, height: 768" into a text box - but then you need that as data to drive nodes. Smart Dictionary from String parses key-value text into an actual DICT that other nodes in this pack (and your graph) can consume programmatically. It's the honest, boring kind of node that you don't appreciate until you're neck-deep in a workflow where a variable's value is a string and you need it to be a number, a list, or a boolean.

The name "Smart" is doing real work: it's not a one-format parser. It shrugs at all the common ways people actually write key-value pairs, and it type-infers the values instead of handing you everything as strings.

How it works

The parser (smart_parse_string_to_dict in the pack's utils.py) works through a decision ladder. First, if the input looks like a Python dict literal - starts with {, ends with } - it tries ast.literal_eval, which safely evaluates real dict syntax. If that fails or isn't the format, it walks through common pair delimiters (,, |, ;, newline) and key-value separators (:, =, =>, ->), splitting pairs and trying each separator in order.

Then the interesting part: it infers types. A value wrapped in brackets gets evaluated as a list. A quoted value keeps its quotes stripped. A string of digits becomes an int or float depending on whether it has a decimal point. true/false become actual booleans. Anything it can't parse stays a string. If every approach fails, it falls back to treating the whole thing as one key-value pair, and if even that fails, you get an empty dict - it never throws, which is the right behavior for a graph node.

The placeholder shows you the expected shape: key1: value1, key2: value2.

The input and output that matter

• input_string - the multiline text with your key-value pairs. Comma-separated is the default habit, but any of the delimiters above work.
• DICT - the parsed dictionary, with type-inferred values.

The DICT output is designed to feed the pack's DictToOutputs node (in the same utils category), which fans dictionary values out to individual typed outputs, or DynamicDictionary for more flexible key handling. That pairing is the real payoff: an LLM spits out a config blob, StringToDict parses it, DictToOutputs splits it into clean wires - no manual copy-paste between nodes.

Installing

This is one node in the drmbt/comfyui-dreambait-nodes pack. Install the pack via ComfyUI Manager (search comfyui-dreambait-nodes) or:

cd ComfyUI/custom_nodes
git clone https://github.com/drmbt/comfyui-dreambait-nodes
# restart ComfyUI

It's a pure-Python utility - no models, no heavy dependencies.

Common issues

The parser is forgiving, but it has opinions. A value like "yes" stays a string (only literal true/false become booleans - case-insensitive), so don't expect enabled: yes to come out as a boolean. Ambiguous formats with multiple delimiters are resolved by whichever pair delimiter appears first in the ladder, so mixing , and | in one string will parse on the first one found. And one legit gotcha: ast.literal_eval is deliberately restrictive (that's what makes it safe), so a dict with JSON-style keys like "key" is fine, but anything involving custom objects will fall through to string parsing. For 95% of "LLM returned a config as text" use cases, you type, it parses, you wire it up.