The first bug that taught me to respect bit widths was a permission flag that kept clearing itself. I was ORing a bitmask into an integer column, and every so often the whole field reset. The cause was embarrassing once I saw it: I was reasoning about the bits as if they lived in 32 slots, but the value had already been widened and a stray NOT somewhere upstream had flipped bits I never accounted for. I fixed it by sitting down with a calculator that showed me the actual bits at the actual width, not the tidy decimal my language printed. This guide is about that habit, using the Binary Calculator on toolz.dev, and why doing bitwise math where you can see every base at once saves hours of guessing.
TL;DR: A binary calculator performs arithmetic (add, subtract, multiply, divide) and bitwise operations (AND, OR, XOR, NOT, shifts) on integers written in binary, octal, decimal, or hex, and shows the result in all four bases at once. Arithmetic is exact at any size; bitwise operations depend on a chosen bit width. The Binary Calculator does both, entirely in your browser, and reports signed and unsigned readings for bitwise results.
What is a binary calculator?
A binary calculator is a tool that operates on integers in base two, but the useful ones are not limited to base two at all. You pick the base you are thinking in, binary, octal, decimal, or hexadecimal, type your numbers, choose an operation, and read the answer. The good ones show that answer in every base simultaneously, so you never run a separate conversion to sanity-check what you got.
The reason this matters is that low-level work constantly crosses between bases. A color is hex, a permission mask is binary in your head but decimal in the database, a network value is octal in one config and decimal in another. Doing the math in one place, with all the representations visible, removes an entire class of transcription mistakes. You are not copying a hex value into a decimal calculator and hoping you converted it right first.
On toolz.dev the flow is short. Choose the input base. Type the first value. Pick an operation. Type the second value. The result appears in binary, octal, decimal, and hex together, and for bitwise operations it also shows the signed reading and the bit layout at your chosen width.
What operations does it support?
Two families, and keeping them straight is the whole game. The arithmetic operations are add, subtract, multiply, divide, and modulo. These act on the true numeric value, so they behave like ordinary math and do not care about bit width. Division returns the integer quotient and reports any remainder, and modulo returns just the remainder, which is the distinction people most often get backwards.
The bitwise operations are AND, OR, XOR, NAND, NOR, XNOR, NOT, and the left and right shifts. These act on the raw bits inside a fixed register, so their answer depends entirely on how wide that register is. AND, OR, and XOR are the everyday three: AND masks bits off, OR sets bits on, XOR toggles them. The negated forms, NAND, NOR, and XNOR, are their complements within the width. NOT flips every bit. The shifts move the whole pattern left or right by a number of positions, dropping the bits that fall off the end.
Here is the quick mental model I use when deciding which one I want:
| Operation | Symbol | Family | Typical use |
|---|---|---|---|
| Add / Subtract | + / − | Arithmetic | Ordinary integer math, any size |
| Multiply / Divide | × / ÷ | Arithmetic | Division reports quotient and remainder |
| Modulo | mod | Arithmetic | Remainder only, e.g. wrap-around indexing |
| AND | & | Bitwise | Mask bits off, test a flag |
| OR | | | Bitwise | Set flags, combine masks |
| XOR | ^ | Bitwise | Toggle bits, cheap parity and swaps |
| NOT | ~ | Bitwise | Invert every bit within the width |
| Shift left / right | << / >> | Bitwise | Multiply or divide by powers of two, pack fields |
Why do I need to choose a bit width?
This is the question that trips up everyone new to bitwise math, and it is the one the calculator is most opinionated about. Arithmetic has an obvious answer no matter the size: five plus three is eight whether you imagine it in a byte or a 64-bit word. But a bitwise NOT has no answer at all until you know how many bits exist. NOT of five is "flip every bit," and the result depends on whether there are eight bits or sixty-four to flip.
Shifts have the same dependency from the other direction. Shift a value left far enough and bits march off the top edge. Whether they vanish or wrap depends on the register size. A fixed-width integer type in C, Java, Go, or Rust answers this by defining the width up front: a uint8 is eight bits, a uint32 is thirty-two, and every bitwise operation happens inside that box. The calculator mirrors that exactly by letting you pick 8, 16, 32, or 64 bits, so the result matches what your actual code will produce rather than an idealized infinite-width abstraction.
Choosing the wrong width is not a rounding error, it is a different answer. NOT of five is 250 in eight bits and 4294967290 in thirty-two. Both are correct for their width, and neither is correct for the other. Getting into the habit of setting the width to match your data type is the single most useful discipline this tool encourages.
How does two's complement show up in the results?
Almost every processor represents signed integers using two's complement, and the calculator follows the same convention so its output matches your hardware. In two's complement, the top bit of the register carries negative weight, so an eight-bit pattern of 11111010 reads as 250 if you treat it as unsigned, or as −6 if you read the top bit as a sign.
This is why the tool reports both readings for a bitwise result. When you run NOT on five in eight bits, you get the bit pattern 11111010. The calculator shows the unsigned value 250, the signed value −6, and the binary layout, so you can see they are the same bits interpreted two ways. That dual reading is exactly what you need when a value crosses between a signed and an unsigned type in your code, which is a classic source of "impossible" numbers appearing in logs.
Arithmetic results follow the same rule when they go negative. Subtract twelve from five and the true answer is −7, which the calculator shows in decimal with a minus sign, while its binary, octal, and hex forms use the two's-complement pattern within your chosen width, 11111001 in eight bits. Seeing the negative value and its bit pattern side by side is how the abstract idea of "the sign is just the top bit" finally clicks.
How do I add or subtract binary numbers by hand, and check it here?
Binary addition follows the same carry rules as decimal, with a smaller alphabet. Zero plus zero is zero, zero plus one is one, one plus one is zero carry one, and one plus one plus a carry is one carry one. So 1010 plus 1100 works column by column from the right: 0+0 is 0, 1+0 is 1, 0+1 is 1, 1+1 is 0 carry 1, and the carry becomes the leading bit, giving 10110, which is 22 in decimal. Punching that into the calculator confirms it in every base at once, which is how I check my hand arithmetic when I am relearning it for an interview or teaching it to someone.
Subtraction is where two's complement earns its keep. Rather than borrow across columns, computers subtract by adding the negative, and the negative is formed by inverting the bits and adding one. You rarely need to do that by hand, but it explains why the calculator can subtract into negative territory cleanly: 5 minus 12 becomes 5 plus the two's-complement of 12, and the result is the −7 pattern described above. If you want to move a single value between bases without doing any math on it, the Number Base Converter is the companion tool, and the Binary Translator handles the case where you are turning text into bits rather than doing arithmetic.
When do bitwise operations actually matter?
More often than beginners expect, and in places that are not obviously "low level." Permission systems are the classic case: a set of flags packed into one integer, where you OR to grant a permission, AND with a complement to revoke it, and AND to test one. Feature toggles, Unix file modes, and hardware register maps all use the same pattern. If you have ever seen a value like 0o755 or a constant defined as 1 << 3, you have met bit packing.
XOR shows up in cheap tricks and real algorithms alike: toggling a bit, computing parity, and the classic swap-without-a-temp. Shifts multiply and divide by powers of two far faster than general multiplication, and they pack several small fields into one word, which is how color values, network headers, and compact serialization formats stay small. I hit these constantly building across the stack, from a Laravel API that stores role flags as a bitmask to a React canvas that reads RGBA out of a packed integer. Understanding the operations is a small investment that pays back everywhere, and I wrote about how these fit a broader kit in the developer productivity tools piece.
The subtle failures are what make a visible calculator worth using. A mask applied at the wrong width silently keeps or drops bits you did not intend. A shift that assumed 32 bits behaves differently at 64. A signed value ANDed against an unsigned mask produces a number that looks impossible until you see the two's-complement bits. Watching the bit layout change as you adjust the width turns those bugs from mysteries into obvious mistakes.
There is a teaching angle here as well. When I explain bitmasks to someone new, decimal numbers are useless: 12 AND 10 being 8 means nothing until you line up 1100 and 1010 and watch the AND keep only the column where both are 1. Because the calculator shows the binary layout beside the decimal, octal, and hex, it does that alignment for you, and the operation stops being a rule to memorize and becomes something you can see. The same is true for shifts, where showing that a left shift by one doubles the value while sliding every bit one column left connects the arithmetic meaning to the bit-level mechanic in a way a single number never can.
What are the limits, and is my data private?
The arithmetic side has effectively no size limit. The calculator uses JavaScript's BigInt, an arbitrary-precision integer type standardized in ECMAScript, so adding or multiplying numbers with dozens of digits stays exact with no silent overflow. This is a real advantage over calculators built on ordinary floating-point numbers, which lose precision past about fifteen digits and cannot represent large integers exactly at all.
The bitwise side is deliberately bounded by the width you choose, because that is the point: a fixed-width operation only makes sense inside a fixed register. If you enter a value larger than the width can hold, the calculator reduces it to that width and warns you, so a truncation never happens silently. Shifts are capped at a sane maximum so a runaway shift amount cannot hang the page.
On privacy, everything runs in your browser. Nothing you type is uploaded, logged, or stored, and the tool keeps working if you disconnect from the internet after the page loads. That matters more than it sounds: the values people run through a bitwise calculator are often permission masks, tokens, or hardware addresses from systems they would rather not paste into a server they do not control. If you care about which tools keep your data on your machine, the data privacy in online tools guide covers how to tell client-side tools from ones that phone home. For neighboring low-level work, the IEEE 754 Converter and the ASCII Table round out the set.
Frequently asked questions
How do I add two binary numbers?
Set the input base to binary, type the first number, choose Add, type the second number, and read the result. For example, 1010 plus 1100 is 10110, which the tool also shows as 22 in decimal, 26 in octal, and 16 in hex. Arithmetic is exact at any length.
What is the difference between arithmetic and bitwise operations?
Arithmetic operations (add, subtract, multiply, divide, modulo) act on the true numeric value and are independent of bit width. Bitwise operations (AND, OR, XOR, NOT, and shifts) act on the raw bits inside a fixed-width register, so their result depends on whether you choose 8, 16, 32, or 64 bits.
Why do I need to choose a bit width?
NOT and shift operations only have a defined answer once the register size is known, because they depend on which bits exist and which fall off the end. Selecting 8, 16, 32, or 64 bits makes the calculator match how a specific integer type behaves in a real programming language.
How does the calculator handle negative results?
Negative arithmetic results are shown with a minus sign in decimal, and their binary, octal, and hex forms use two's-complement within the selected width. For bitwise results, the tool reports both the unsigned value and the signed two's-complement value.
Can I mix bases, like adding a hex number to a decimal one?
Both operands are read in the single base you select, so you cannot mix bases in one calculation. To combine a hex and a decimal value, first convert one of them, then enter both in the same base. The result is always displayed in all four bases.
What does the calculator do when I divide?
Division returns the integer quotient, and if the division is not exact the tool reports the remainder as a note. To get the remainder on its own, use the Modulo operation instead, which returns only the remainder.
How large can the numbers be?
Arithmetic uses JavaScript BigInt, so numbers with many dozens of digits are handled exactly with no overflow. Bitwise operations are bounded by the chosen width; values that exceed it are reduced to that width, and the tool warns you when that happens.
Is my data sent anywhere?
No. Every calculation runs as JavaScript in your browser. Nothing you type is transmitted, logged, or stored, and the tool continues to work if you disconnect from the internet after the page loads.
Try the math yourself with the free Binary Calculator. It handles arithmetic and bitwise operations across binary, octal, decimal, and hex, entirely in your browser, with nothing uploaded.
