Hex AND Calculator — Bitwise AND on Hexadecimal Numbers

What is a hex AND calculator?

A hex AND calculator performs the bitwise AND operation on two hexadecimal numbers and returns the result in hex. Bitwise AND compares two values one binary bit at a time: for each bit position, the result is 1 only when both input bits are 1, and 0 otherwise. Because a single hex digit represents exactly 4 binary bits (a nibble), the operation naturally works on hex in 4-bit chunks.

This is the operation behind bit masking — the technique of extracting specific fields from a packed value, clearing unwanted bits, or checking whether a flag is set. When you write value & 0xFF in C, C++, Java, Python, JavaScript or Go, you are asking: "keep only the lowest 8 bits, discard everything above." A hex AND calculator lets you run that operation without spinning up an IDE — useful when you're reading a hardware datasheet, debugging a protocol capture, or verifying a subnet calculation by hand.

This tool is built around that workflow. The operation is focused on AND — with the hex-first input, the bit-position visualization, the nibble-by-nibble breakdown and the mask presets all designed for the way developers actually use the operation. OR, XOR and NOT are available as additional tabs, but every part of the interface is optimized for AND.

💡 Quick example. 0xF0 AND 0x0F = 0x00. In binary: 1111 0000 AND 0000 1111 = 0000 0000. The high nibble (F0) has no 1-bits in the same positions as the low nibble (0F), so every AND result bit is zero.

Hex AND is not decimal AND — a caution

This trips people up constantly. Bitwise AND operates on the binary representation of the numbers, not on their decimal values. So 0x10 AND 0x0F is 0x00, but 10 AND 15 — if you were foolish enough to treat those as decimal digits and AND them digit-by-digit — would look like nonsense.

The rule is: hex is notation. The calculator converts every hex digit to its 4-bit binary form before doing the operation, so 0x10 is really 0001 0000 and 0x0F is really 0000 1111. Their AND is 0000 0000 = 0x00. The decimal value 16 ANDed with the decimal value 15 also gives 0, because both are the same bits behind the scenes. The confusion only arises if you imagine the operation running on the decimal digits themselves — it doesn't.

If you're ever unsure, remember: convert to binary first, then AND bit-by-bit. Every hex AND result is exactly the same as the corresponding binary AND result and exactly the same as the corresponding decimal AND result — provided you're consistent about the actual numeric value.

The AND truth table

Bitwise AND has just four possible input combinations and one output. Only one row produces a 1 — and that single 1-row is what makes AND a masking operator. You choose which positions survive by placing 1s in the mask at those positions; everywhere the mask has 0, the result is 0.

The result row highlighted by the tool shows which of these four combinations actually occurred in your input. For an AND between two different hex values, only one or two rows are typically used — most of the operation is zeros on zeros.

How to AND two hex numbers step by step

The bitwise AND operation on hex values follows three steps. The method below is exactly what this calculator performs internally — the nibble table below the result shows every stage.

1. Convert each hex digit to 4 binary bits. Use the standard mapping: 0 → 0000, 1 → 0001, 2 → 0010, … 9 → 1001, A → 1010, B → 1011, C → 1100, D → 1101, E → 1110, F → 1111. This turns 0xF0 into 1111 0000 and 0x0F into 0000 1111.
2. Align the two binary strings and AND each pair of bits. The bits line up by position: the rightmost bit of A against the rightmost bit of B, then the next position, and so on. Apply the truth table to every position.
3. Regroup into 4-bit nibbles and convert each back to hex. The result bits are grouped from the right in blocks of four, and each block is translated back to a hex digit.

Worked example — 0xF0 AND 0x0F:

Line up the bits and AND each column: 1111 0000 & 0000 1111 = 0000 0000. The result nibbles are 0000 and 0000, which convert back to 0x00.

Worked example — 0xABCD AND 0xFF00:

Expand: 0xABCD = 1010 1011 1100 1101 and 0xFF00 = 1111 1111 0000 0000. The AND keeps only the upper byte because the mask's lower byte is zero:

The nibble-by-nibble shortcut

Once you've done a few hex ANDs by hand, you stop expanding to binary and start working directly on the hex digits. Each hex digit in A is ANDed with the corresponding digit in B, independently of the others. Because hex digits map 1-to-1 to nibbles, this is exactly the same operation — just compressed:

The calculator performs the per-nibble AND automatically and displays the result in the nibble breakdown table below the main answer. This makes the operation easy to verify by eye — you can check each nibble in isolation rather than re-deriving the whole thing.

💡 AND is the only bitwise operation that is distributable over nibbles. Because each pair of hex digits occupies its own 4-bit slot, an AND on the whole number equals the concatenation of ANDs on each nibble. The same is true for OR and XOR. This is what makes hex the natural notation for masking — it mirrors the underlying bit structure one digit at a time.

Why use AND specifically?

Bitwise AND is not one of four interchangeable logical operations — it is the masking operator. OR sets bits, XOR toggles bits, but AND keeps bits and zeroes everything else. Every time you want to look at part of a value rather than the whole, AND is the tool.

Real-world cases where hex AND is exactly the right operation:

• Extracting a byte from a 32-bit value. value & 0xFF000000 gives the high byte, value & 0x000000FF the low byte, and so on. This is the standard way to break a big value into fields.
• Reading individual flags from a status word. If bit 3 encodes "connected" and bit 7 encodes "ready", you test status & 0x08 and status & 0x80. Non-zero means the flag is on.
• Extracting channels from an ARGB color. 0xAARRGGBB & 0x00FF0000 gives just the red channel, positioned so you can shift it into the right byte.
• Computing an IP network address. A subnet mask is applied to an IP address with AND to zero out the host portion. 192.168.1.100 & 255.255.255.0 = 192.168.1.0. This is not a niche use — it is the canonical bitwise AND example.
• Parsing protocol headers. The IP version and header-length fields both live in the first byte of an IPv4 header. 0x45 & 0xF0 = 0x40 gives the version, 0x45 & 0x0F = 0x05 gives the IHL in 32-bit words.
• Forcing a value to a lower range. x & 0x7F ensures the result fits in 7 bits, regardless of what was in x.
• Clearing specific bits. ANDing with a mask that has 0s in the positions you want cleared sets those bits to zero without touching the rest.

Bitfield extraction patterns

The classic workflow in embedded and systems code is: pack several small fields into one word on the sender side, then unpack them with masks and shifts on the receiver side. Hex AND is the "unpack" half of that workflow.

In practice, extracting the third byte of a 32-bit value looks like this: (value & 0xFF0000) >> 16. The AND isolates the byte; the shift moves it into the low byte so it can be used as an 8-bit integer. This pattern repeats in every layer of every operating system.

Common hex masks

These masks appear constantly in real code. Every one of them has a specific job:

The mask presets in the calculator load the most common of these into field B with one tap.

Word size and masking

The word size selector (Auto / 8-bit / 16-bit / 32-bit / 64-bit) does two things: it sets the width of the bit visualization, and it masks the result to that width after the operation. For AND, OR and XOR this matters when the two operands have different natural widths — setting 8-bit forces the operation to happen in exactly 8-bit space and truncates anything above bit 7.

For NOT specifically, the word size changes the answer dramatically. NOT 0x0F produces:

• 0xF0 in 8-bit (flip 8 bits)
• 0xFFF0 in 16-bit (flip 16 bits)
• 0xFFFFFFF0 in 32-bit (flip 32 bits)

That is why NOT always needs a word size to be meaningful — the mathematical result of inverting an infinite-precision integer is not what you want. AND/OR/XOR do not have this ambiguity: their result is the same regardless of the width, as long as both operands fit.

Bitwise AND in IP subnetting

The most common real-world bitwise AND is not in code — it is in networking. Every time a computer sends a packet, it checks whether the destination is on the local subnet by ANDing the destination IP address with the subnet mask. This is the canonical use of the operation and it works exactly like a hex mask on a packed value.

An IPv4 address and a subnet mask are both 32-bit values. When you write 192.168.1.100/24, you are saying: the first 24 bits of the address are the network portion and the last 8 bits are the host portion. Converting to hex:

The result 192.168.1.0 is the network address. Every device on the same subnet produces the same result, which is how routers decide whether to forward a packet locally or send it to the gateway.

The IP subnet mask presets in the calculator load 0xFF000000 (/8), 0xFFFF0000 (/16), 0xFFFFFF00 (/24) and 0xFFFFFFF0 (/28) into field B with one tap. Paste the hex equivalent of any IP address into field A and the network address drops out instantly.

How AND works with negative numbers (two's complement)

In most languages, negative integers are stored in two's complement — the value −1 is all-bits-set (0xFFFFFFFF in 32-bit), −2 is all-bits-set minus one, and so on. Bitwise AND works on those bit patterns exactly as it works on positive numbers: it does not care whether the interpreter treats the value as signed or unsigned, because the operation is defined on the bits.

Two consequences are worth knowing:

• ANDing with a mask extracts fields regardless of sign. If value is negative, value & 0xFF still returns its low byte as a positive integer between 0 and 255. This is how you safely unpack a signed 32-bit value into its constituent bytes.
• AND is not a "sign-aware" operation. -1 & 0x0F = 0x0F, not -1. The mask clips the negative number to the field you asked for. If you need to preserve the sign, use a mask that keeps the sign bit and then reinterpret.

The calculator shows the decimal readout as the unsigned value of the result, which matches how the operation actually behaves at the bit level.

Common mistakes with hex AND

• Confusing AND with OR. AND is 1 only when both bits are 1. OR is 1 when either bit is 1. They are not interchangeable. If your mask is supposed to isolate bits, you want AND — using OR would set every bit the mask has set, which is a completely different result.
• Forgetting to convert hex to binary when doing it by hand. You cannot AND hex digits as if they were decimal numbers. You need to expand each hex digit to 4 bits and AND the bits, then regroup.
• Using the wrong mask width. To isolate the low byte you want 0xFF, not 0xF or 0xFFF. Off-by-one in the mask produces the wrong field.
• Assuming hex AND works the same on signed integers. In most languages, negative integers are stored in two's complement. ANDing a negative number with a mask still works bit-by-bit, but the result may not be what you expect if you were thinking of the value as decimal.
• Confusing AND with decimal masking. 0x123 AND 0x0F does not give "the last decimal digit." It gives the last hex digit — 0x03 in this case.
• Expecting AND to work like a filter that preserves the larger input. The result of A AND B is always ≤ min(A, B) bit-by-bit — you can never gain a bit that was not in both operands. This is not intuitive if you're used to arithmetic.
• Forgetting that a mask of all-1s is a no-op and a mask of all-0s is a reset. x & 0xFF leaves x unchanged if x fits in 8 bits, and x & 0x00 is always 0. Both are useful edge cases, not bugs.
• Mixing up byte order when unpacking multi-byte fields. A 32-bit value 0xAABBCCDD has byte 3 = AA, byte 2 = BB, byte 1 = CC, byte 0 = DD in big-endian. On little-endian machines the same value can be interpreted as DD CC BB AA. Always check endianness before assuming a mask returns the field in the order you expect.

Privacy and data storage

Everything runs in your browser. The conversion, the bit visualization, the truth table, the nibble breakdown and the arithmetic all happen locally in JavaScript using BigInt. Nothing you type is uploaded to a server. There is no account, no login and no network request after the page has loaded — the calculator works offline once the page is cached.

Limitations

• The calculator handles bitwise operations only — AND, OR, XOR, NOT. It does not perform hex arithmetic (addition, subtraction, multiplication, division). For hex arithmetic, use a general hex calculator.
• The word size options cap at 64 bits. Values wider than that can still be entered on Auto word size, but the bit visualization is truncated to 64 bits for display with a warning banner. The numeric result is always exact.
• Signed interpretation (two's complement) is shown as a secondary readout only. The primary result is always the unsigned bit pattern — the operation itself does not change based on sign.
• Leading zeros do not affect the AND result, so the calculator displays a natural-width result unless you set a fixed word size.
• Shifts (left and right) are not included. This tool is focused on bitwise logic, not bit manipulation. For shifts, use a dedicated shift calculator.
• Only two operands are supported. ANDing three or more values requires chaining — the result of the first operation feeds into the next.

Frequently asked questions

Related tools on AIToolsPros