Create Lora Mapping Json

Convert Lora Keys needs a mapping - a JSON file that says "this key becomes that key." If you're converting a big LoRA, hand-typing that mapping means hundreds of lines of fragile JSON. Create Lora Mapping Json exists to type it for you: you give it two LoRAs, it studies their key structures, and it produces a mapping from the keys of LoRA A to the keys of LoRA B.

Think of it as the scaffolding step. You load the LoRA you want to convert (A, the source) and the LoRA whose naming you want to match (B, the target). The node walks both state dicts and groups keys by their core structure - things like transformer_blocks.N, input_blocks.N, output_blocks, time_emb, or a diffusion_model prefix. Keys that already match exactly are mapped to themselves; the rest get paired up structure-by-structure. The output is a mapping_json string you can feed straight into Convert Lora Keys.

Now the part you actually need to hear, because this is a heuristic, not an oracle. When the two LoRAs share a structure, it pairs their keys in list order - it does not analyze whether loraA[key_1] and loraB[key_2] are semantically the same layer. If both files are cleanly organized with matching conventions, the mapping comes out right. The moment ordering differs, or one file uses a naming scheme the heuristics don't recognize, you get pairs that look plausible and are wrong. The fallback path even strips LoRA-specific suffixes and matches on whatever's left, which is exactly the kind of "close enough?" matching that needs a human eye.

So the workflow that works: run this node, read the mapping_json in a text display, scan the rows for anything that looks off, edit as needed, then paste into Convert Lora Keys. Remember that Convert drops unmapped keys, so a partial mapping from a botched heuristic produces a silently crippled LoRA. Also worth saying: if both LoRAs are from the same trainer and same family, most keys match identically and this node is overkill - a mapping of self-identical keys is a mapping you barely need.

You might also ask the fair question: is key conversion even worth it? Converting a LoRA's key names doesn't change its weights, and it definitely doesn't make an SDXL LoRA work on Flux - the architecture gap runs deeper than naming. Where it genuinely pays off is porting between naming conventions that are otherwise compatible: same family, different trainer habits. Anything more ambitious than that, and you're polishing a turd, as the saying goes.

Installation is the pack's standard two-liner, no extra dependencies beyond what ComfyUI ships:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-LoraUtils

Restart ComfyUI and the nodes appear under LoraUtils; ComfyUI Manager users can search Comfyui-LoraUtils. It's a small pack by lrzjason (a.k.a. xiaozhijason on Civitai) with a quiet footprint, which sums it up: a genuinely handy helper that expects you to be the adult in the room.