Loading Bitwise Calculator…
Decimal, or prefixed: 0x for hex, 0b for binary, 0o for octal. Spaces and underscores are ignored.
A bit is set only where it is set in both operands. Used to mask bits off.
NOT is the only unary operator here; every other one uses both operands.
182 & 15 = 6
32-bit two’s complement, with the bits grouped in fours
0000 0000 0000 0000 0000 0000 1011 01100000 0000 0000 0000 0000 0000 0000 11110000 0000 0000 0000 0000 0000 0000 0110A decimal result tells you very little about a bitwise operation. This calculator prints both operands and the result in binary, hexadecimal and decimal at once, the binary padded to a full 32 bits and grouped in fours, because 1011 0110 is legible where 10110110 is a counting exercise. Masking 182 with 15 is then obvious: 1011 0110 AND 0000 1111 leaves 0000 0110, which is 6 — low nibble kept, high nibble discarded.
Operands can be typed in whichever base you are thinking in: 0x for hex, 0b for binary, 0o for octal, with spaces and underscores between digits ignored, and a sign in front of a prefix accepted even though BigInt itself rejects that form.
This is the trap the language builds in. Numbers in JavaScript are 64-bit floats, but &, |, ^, ~, << and >> all convert their operands to signed 32-bit integers first, so results that look like faults are the specification working as written. Flipping every bit of 0 gives all ones, and all ones as a signed value is −1, so ~0 is −1 and ~5 is −6. Shifting 1 up by 31 places lands on bit 31, which is the sign bit, so 1 << 31 is −2147483648 rather than the 2147483648 you were reaching for.
The conversion wraps rather than clamping or complaining. 3000000000 & -1 does not return 3000000000; it returns −1294967296, because the input was reduced modulo 2^32 first. Shift counts get the same treatment from the other end: only the low five bits of the right operand are used, which is why x << 32 returns x unchanged instead of zero, and x << 33 is the same as x << 1. All three behaviours are called out on screen when they affect your result.
The unsigned right shift is the single operator that reads its left operand as a uint32, and its result is unsigned too. That makes -1 >>> 0 evaluate to 4294967295, which is the standard idiom for viewing a signed value as unsigned — the shift by zero moves nothing and exists purely to force the coercion.
Its sibling >> does the opposite: it copies the sign bit inward as it shifts, so a negative stays negative and -16 >> 2 is −4. The same operands through >>> give 1073741820, the vacated top bits filled with zeros instead. Neither is broken; they answer different questions.
Internally every value is held as a BigInt and the 32-bit coercion is applied deliberately, which makes the wrap something the tool can report rather than something that happens silently. It also allows the honest answer to be shown next to the truncated one: an overflowing left shift such as 3 << 30 reports −1073741824 as JavaScript computes it, and 3221225472 as the arithmetic actually goes, because a BigInt has no fixed width to overflow.
BigInt is not a drop-in replacement, though, and the gap is instructive. It has no >>> operator at all — an unsigned right shift needs a top bit to shift zeros into, and an arbitrary-precision integer does not have one — so the unsigned shift here is a masked >> instead. Mixing a BigInt with a Number in the same expression also throws a TypeError rather than converting, and BigInt.asIntN(32, value) is how you ask for the 32-bit wrap explicitly when you want it.
Because NOT flips all 32 bits, not the eight you were picturing, and the top bit it flips is the sign bit. In two’s complement that makes ~n equal to −(n + 1) for every integer. To flip only the low byte, use ~n & 0xFF.
Append >>> 0 to the expression. It shifts nothing and simply reinterprets the same 32 bits as unsigned, turning −1 into 4294967295. This calculator shows that unsigned reading beside any negative result so the conversion is not needed by hand.
Not with the ordinary operators, because bit 31 is the sign bit and bit 32 does not exist for them. Either move the whole set to BigInt, where 1n << 40n is exact, or split the flags across two 32-bit fields.
No. Modern engines optimise both, and the shift adds a conversion to 32-bit integer that multiplication does not have — so for values above 2^31 the shift is not merely no faster, it is wrong. Write the arithmetic you mean.
Because the shift count is taken from the low five bits of the right operand, giving a range of 0 to 31. A count of 32 becomes 0, so nothing moves. Shifting by 32 or more requires doing it in two steps, or using BigInt.