What "different" means at the bit level
Two hex values can look completely different from each other while actually sharing almost every bit, or look nearly identical while differing in a way that matters a great deal — hex notation compresses four bits into one character, so a single differing bit can either change a hex digit completely or leave it looking deceptively close to the original. Comparing two values bit by bit, rather than eyeballing their hex or decimal representations, is the only way to see exactly which positions changed and how many did, independent of how that difference happens to render as text.
Why this is the same operation as XOR
XORing two values produces a 1 in every position where they differ and a 0 everywhere they match — which is precisely the "diff mask" this tool computes and highlights on the bit grid. The Hex Bitwise Calculator exposes that same XOR operation directly, for when the result itself needs to feed into a larger calculation rather than just be inspected visually. This tool exists as a dedicated, side-by-side view of that comparison — the bit grid for A, the bit grid for B, and every differing position ringed on both, rather than a single abstract result value.
Hamming distance: giving the difference a number
Counting how many bit positions differ between two equal-length values is called the Hamming distance, named after Richard Hamming's 1950 work on error-detecting codes at Bell Labs. It answers a specific, useful question: how many single-bit flips would it take to turn one value into the other? A Hamming distance of 1 means a single corrupted bit could explain the entire difference — worth investigating as a possible transmission or memory error. A high Hamming distance, close to the full bit width, suggests the two values are unrelated rather than one being a slightly-corrupted version of the other.
Where bit-level comparison is actually useful
Comparing two memory dump snippets before and after a suspected corruption event, checking whether two checksums or hash outputs that should be identical actually match exactly bit for bit, or verifying that toggling what should be a single flag in a packed status register only changed the one intended bit — all of these are cases where the numeric difference between two values (subtraction) tells you almost nothing useful, but the bit-level difference tells you exactly what changed. A register value going from 0x3C to 0x3E is only 2 apart numerically, and is also only one bit apart at the bit level in this case — but that won't always coincide, and only the bit-level view is reliable for questions like "did exactly one flag flip."
Why bit width has to be chosen deliberately
Comparing 0xF against 0x1F only makes sense once both are expressed at the same bit width — at 8 bits they're 00001111 and 00011111, differing in exactly one position, but reading them as different-length values without a shared width to pad against would be comparing apples to oranges. Choosing a bit width wider than either value needs is harmless — the extra leading positions are zero in both and simply never register as a difference — but choosing one narrower than either value can represent will silently truncate meaningful high-order bits, which is why this tool masks both inputs to the selected width the same way the bitwise and shift calculators do.
Comparing more than one pair at once
The batch mode above runs the same comparison across a full list of value pairs — useful for checking, say, every register in a dumped state block against its expected value in one pass, rather than pasting each pair in individually. Each row reports both the Hamming distance and the diff mask in hex, and the full batch result exports to CSV like every other batch tool on this site.