LoRA Tags To Hash Metadata

CivitAI doesn't figure out which LoRAs you used by reading your prompt. It matches resources to uploaded images by file hash - and if your saved PNG carries no hash metadata, the "resources" panel on your post stays empty and the LoRA creators you borrowed from get no credit. That's the whole problem this node exists to solve.

LoRA Tags To Hash Metadata is the v1 half of the comfyui-lora-tag-hash-metadata pack. You already have a workflow full of <lora:name:weight> tags - from LoRA Manager, rgthree's loader, or a plain Lora Loader. This node converts those tags into the Name:HASH:Weight strings that a metadata saver can embed into the image, so CivitAI's hash matcher can actually find and credit your LoRAs.

How it works

The nice part: it does all the work locally, no API, no key, no network. The node parses each <lora:name:weight> tag, locates the actual model file in your models/loras folder (it tries the path-qualified name first, then a basename fallback), computes the file's SHA256, and emits the first 10 hex characters in uppercase - exactly the short hash format CivitAI matches on. Weight defaults to 1.0 when you leave it off, and LoRA Manager's dual-strength form <lora:name:model:clip> is accepted too (the model strength is the credited weight). Duplicate tags are deduped with the last one winning.

Because it hashes your real file, it's deterministic and offline-friendly. Because it's a real file hash, there's also a subtle cost: rename or replace the LoRA and the hash changes, so an old upload won't match the new file.

The inputs and outputs that matter

The only input is loaded_loras - a multiline string of <lora:name:weight> tags. That's it. Wire it straight from whatever produces your lora tags (LoRA Manager exposes them, and rgthree-style loaders do too).

Three outputs, and only one you'll actually connect:

• additional_hashes - the comma-separated Name:HASH:Weight string. Feed this into Image Saver Metadata's additional_hashes input and you're done.
• resolved_loras / missing_loras - comma-separated lists for debugging: which names got a hash and which didn't (e.g. a typo, or a file that isn't in your loras folder).

Installing it

Both nodes in this pack ship together, so this installs v2 as a bonus. Via ComfyUI Manager: open Manager → Install Custom Nodes → search LoRA Tag Hash Metadata → Install → restart. Or from the terminal:

cd ComfyUI/custom_nodes
git clone https://github.com/PBandDev/comfyui-lora-tag-hash-metadata

then restart ComfyUI. No model downloads, no pip dependencies, no API key. Two real requirements: a reasonably recent ComfyUI (the pack targets the newer node API, >= 0.3.0), and - if you cloned from git - the frontend build isn't in the repo, so run pnpm install && pnpm build in the folder or the v2 picker UI won't appear. Manager installs get the prebuilt version automatically.

Where people get burned

The big one is downstream, not here: Image Saver only parses Name:HASH:Weight three-part entries when download_civitai_data is True (the default). Flip it off and your hashes get silently dropped - this affects all v1 output since it's always weighted. Keep it True.

The other common miss: the file must exist on disk under your loras folder for the hash to be computed, so a missing LoRA lands in missing_loras rather than erroring out. And names containing commas can't be credited - they're reported as missing instead of silently breaking the comma-separated output. If your workflow uses lots of LoRAs, also note Image Saver ignores manual hash entries past 30.

It's a small node doing one thing. But if you share generations on CivitAI and care that the people whose LoRAs you stacked actually get the credit, it's the difference between an empty resources panel and a properly attributed one.