Four operations, one bit at a time
Bitwise operations act independently on every bit position of their operands — there's no carrying, borrowing, or interaction between adjacent bits the way ordinary addition or subtraction has. AND produces a 1 only where both operands have a 1 at that position, and 0 everywhere else. OR produces a 1 where either operand has a 1. XOR (exclusive or) produces a 1 only where the operands differ — one is 1 and the other is 0 — and 0 where they match. NOT simply flips every bit of a single operand, 1s to 0s and 0s to 1s. Because each bit is evaluated independently, these operations are extremely fast in hardware and form the basis of nearly every other bit-manipulation technique.
Practical uses: masking, setting, and testing bits
AND is most commonly used to mask — isolate a subset of bits while zeroing the rest, useful for extracting one field from a value packed with several. OR is used to set specific bits without disturbing the others, common when combining independent flag values into one packed field. XOR has two distinctive uses: toggling specific bits (XORing with 1 flips a bit, XORing with 0 leaves it unchanged), and detecting differences (XORing two values highlights exactly which bits differ between them, which is also the core operation behind the parity and checksum calculations used in error detection). NOT is used to build the inverse of a mask — flip a bit pattern before combining it with AND to clear specific bits rather than set them.
Why the bit-grid visualization matters here specifically
Bitwise results are notoriously hard to sanity-check from the hex value alone, because a hex digit represents four bits at once and a single wrong bit anywhere in that nibble can produce a completely different-looking hex character with no visual clue about which specific bit changed. Seeing the full binary expansion of both operands and the result side by side — which is what the live grid above provides — makes it possible to directly verify, bit by bit, that an AND correctly zeroed the intended positions, or that an XOR toggled exactly the bits expected, rather than trusting the hex result and hoping the underlying operation did what was intended.
Bit width still matters for these operations
AND, OR, and XOR themselves don't inherently depend on bit width the way shifts and NOT do — combining two 4-bit values bit-by-bit works the same regardless of whether the surrounding system considers them 8-bit or 64-bit values. NOT is the exception among these four: flipping "all the bits" only means something once the total number of bits is fixed, since NOT 0x0F is 0xF0 at 8 bits but 0xFFFFFFF0 at 32 bits — the same starting value, inverted against a different total number of bit positions, produces a completely different result. This is exactly analogous to why the shift and two's-complement tools also require a declared bit width.
A worked masking example
Take a packed byte 0xB7 where the low nibble stores one piece of data and the high nibble stores another, and the goal is to read just the low nibble. ANDing with the mask 0x0Fzeroes out the high nibble entirely while leaving the low nibble untouched: 0xB7 AND 0x0F = 0x07. To instead read only the high nibble, AND with 0xF0 and then shift the result right by 4 to move it into the low position: 0xB7 AND 0xF0 = 0xB0, then 0xB0 >> 4 = 0x0B. This mask-then-shift pattern — isolate the bits of interest, then reposition them — is the standard technique for reading any sub-field out of a packed value, regardless of how many fields are packed together or how wide each one is.
Where these operations appear in real code
Flag enums and permission systems (Unix file permissions, HTTP method flags, graphics API state flags) are almost universally implemented as bitmasks combined with OR and tested with AND. Cryptographic primitives, hash functions, and checksums — including the CRC-32 algorithm covered elsewhere on this site — rely heavily on XOR as a core building block, since XOR is its own inverse (XORing twice with the same value returns the original), a property that makes it useful for reversible transformations. Color-blending and image-processing code frequently uses bit shifts combined with AND/OR to pack and unpack individual RGB channels from a single 32-bit pixel value, directly analogous to the byte-splitting this site's own Hex ↔ RGB converter performs.