contains key

Before you reach into a dictionary for a value, it's usually wise to check the key exists - otherwise you're staring at a "KeyError" or a silent None and wondering what happened. DictContainsKey answers the one question that matters first: does this dictionary contain that key? Yes or no, one output, no drama.

Inputs: input_dict (a DICT) and key (a STRING, default empty). Output: a single BOOLEAN - True if the key is present, False if it isn't.

How it works

Under the hood it's the Python membership check key in input_dict. That's the whole mechanism - no iteration of your own, no counting, no manual scan. It checks the dictionary's keys directly, which is fast even on big dicts, because that's what Python dicts are optimized for.

The key input is a plain string, and it's an exact match: "Seed" will not match "seed", and "model" will not match "model " with a trailing space. Dictionaries are case- and whitespace-sensitive, and so is this node. If your keys come from somewhere with inconsistent formatting, normalize them upstream or you'll chase a false False.

Why you'd use it

The classic pattern is a guard before a read. Wire a BOOLEAN out of this node into the pack's if/else or flow-select nodes: if the key exists, branch to the DictGet that reads it; if not, route to a default value or a different path entirely. It's the difference between a workflow that explodes on an unexpected metadata dict and one that shrugs and handles it.

It's also a handy debugging probe - check whether a metadata blob from a loaded image actually carries a field you're relying on before you build the rest of the pipeline on that assumption. Five seconds of checking now beats an hour of "why is this value empty?" later.

Installing it

Part of StableLlama's Basic data handling pack - pure Python, zero dependencies, no model downloads:

cd ComfyUI/custom_nodes
git clone https://github.com/StableLlama/ComfyUI-basic_data_handling

Restart ComfyUI, or search "Basic data handling" in ComfyUI Manager. The pack has no third-party dependencies, so install is the clean two-step it should be.

Common issues

Beyond the exact-match gotcha, the only real trap is feeding it a None or non-dict value - a DICT input that turns out to be missing upstream will error before this node even runs, so check the wire feeding input_dict if you see a failure. And remember the output is a boolean, not the value: this tells you the key exists, not what it holds. Pair it with DictGet for the actual read, and you've got a safe two-node pattern for any optional metadata.