Bitwise Left Shift Operator

Bitwise left shift is the bit fiddler's <<: take every bit, push it left, and fill the hole on the right with zeros. Shift 1 (0001) left by one and you get 2 (0010); shift it left by three and you get 8 (1000). Because the result carries whatever the shifted-out bit was into the next position, left shifts are how a lot of encoding tricks work under the hood - and in the ARG Toolkit's bitwise utility family, this is the node that does the pushing, with the same auto-detecting convenience as its AND/XOR siblings.

Like every operator in the pack's Bitwise menu, BitwiseLS doesn't make you work in raw bytes. You pick a datatype (String, Hexadecimal, Base64, Integer, or Binary), feed two values in that format, and the node parses them, shifts, and hands the result back in the same format you came in with. The catch is in what the two inputs mean. With AND, both inputs are operands. Here, text_1 is the value being shifted and text_2 is the shift amount - the tooltip calls text_1 "the main string" and text_2 "the secondary string," and the shift happens per byte: byte 1 gets shifted by the amount given by byte 1 of text_2, and so on.

The inputs that matter

• text_1 - the value to shift.
• text_2 - the shift amounts. Since shifts are per-byte and pairwise, both inputs must be the same length - the node enforces it with a clear error if they're not.
• datatype - the format of both inputs (and of the output).
• encoding_format - used only when datatype is String, to decide how text becomes bytes.

Output is bitwise_txt (STRING), in the input's format.

Where people get burned

The same-length rule bites here exactly as it does for AND - if text_1 and text_2 differ in length, you get the "Inputs must be same length for bitwise operations" error. And there's a second, easier-to-miss gotcha: shifting left pushes bits out the top. Bytes are 8 bits wide, so shifting a byte left by 8 (or more) produces a zero byte, and the bits that fell off the end are gone. If your result looks like it "lost data," that's not a bug - that's what left shift does. For multi-byte values where you want the carried bits to survive, this particular implementation shifts each byte in place, so plan your shifts to stay within a byte or you'll be surprised.

Also worth a moment: in Integer datatype, text_2 being a small number is fine, but in String datatype, the "shift amount" is per-byte of the string - so a shift string of "1" is bytes [49] (the ASCII code for '1'), not the integer 1. If you want a numeric shift amount, use the Integer datatype. That mismatch is the sneakiest trap in this family.

Installing it

Standard ARG Toolkit install:

cd ComfyUI/custom_nodes
git clone https://github.com/AzelusLightvale/ComfyUI-ARG-Toolkit

Restart ComfyUI and it's under ARG Toolkit → Utilities → Bitwise (ComfyUI Manager: search "ComfyUI ARG Toolkit"). Pure Python stdlib, no extra dependencies, no models.

Troubleshooting

• Length error → pad text_1/text_2 to equal lengths first.
• Result has zeros where you expected data → bits shifted out the top are gone; keep shift amounts under 8 per byte.
• Shift amount isn't what you typed → in String mode, text_2 is bytes, not digits. Use Integer datatype for a real numeric shift.

Left shift is one of those operations that looks trivial until a puzzle makes you reconstruct a value from shifted pieces - then you're grateful it's a node. Pair it with the pack's other bitwise operators and you can build byte-level puzzles entirely inside ComfyUI.