Number base converter

What this tool does

The same number can be written in many bases, and programmers move between four of them constantly: binary because that is what the hardware holds, hexadecimal because it is a readable shorthand for binary, decimal because that is how people think, and octal because file permissions and a few older systems still use it. Type a value into any of the fields here and the rest follow, along with one more field you can set to any base from 2 to 36.

What separates this from a school calculator is the width selector and the bit grid. Pick 8, 16, 32 or 64 bits and negative numbers get their real machine representation instead of a minus sign, and every bit becomes something you can click.

What a base actually is

A base is how many digits you have before you run out and have to carry. Decimal has ten, so after 9 comes 10. Binary has two, so after 1 comes 10. The position of each digit is a power of the base, and that is the whole of it:

1011           # the number, in base 2
1 x 8 = 8      # bit 3
0 x 4 = 0      # bit 2
1 x 2 = 2      # bit 1
1 x 1 = 1      # bit 0
8+0+2+1 = 11   # the total, in decimal

Bases above ten need more than ten digit symbols, so they borrow letters: hexadecimal runs 0-9 then a-f, where a is 10 and f is 15. That continues all the way to base 36, which uses every digit and every letter — the largest base you can write with the plain alphabet, and the reason this tool stops there.

Why hexadecimal, and not something else

Hex is popular for one specific reason: 16 is 2 to the power of 4, so exactly one hex digit covers exactly four bits. That makes the conversion between hex and binary a lookup with no arithmetic — each hex digit expands to its own four bits, independently of the digits around it.

d    e    a    d
1101 1110 1010 1101   # each hex digit is its own nibble

Octal works the same way with three bits per digit, since 8 is 2 to the power of 3 — which is why Unix permissions are octal: three permission bits per group of users fits one digit exactly. Decimal has no such relationship with binary, which is why converting between them requires real division rather than a lookup.

This is also why the binary field here is grouped into fours and the hex field into pairs: the groups line up with the boundaries that matter, so you can read a nibble or a byte off the screen without counting.

Negative numbers and two’s complement

A negative number has no binary form on its own. There is no minus sign in a register — only bits — so the sign has to be encoded in the bits themselves, and that requires deciding how many bits there are. This is why the width selector exists, and why the answer changes when you change it.

The scheme every modern machine uses is two’s complement: to represent a negative number, take its positive form, invert every bit, and add one. The result is that the top bit ends up meaning "negative", and ordinary addition keeps working without any special case for signs.

0000 0101   # 5
1111 1010   # every bit inverted
1111 1011   # plus one: -5 as a byte, or fb in hex

Widen the register and the same number gets a different pattern: -5 is fb in 8 bits, fffb in 16 and fffffffb in 32. The value has not changed; the number of bits carrying it has. Switching width in this tool shows exactly that.

Why 0xFF is both 255 and −1

The bits ff do not say whether they are signed. A byte holding 1111 1111 reads as 255 if the code that loads it declared an unsigned type, and as −1 if it declared a signed one. Nothing in the byte itself distinguishes the two — the type is a claim the program makes about bits that carry no such information.

That is the source of a whole family of real bugs: a checksum that comes out negative, a byte read from a file that compares as less than zero, a C char that behaves differently on ARM than on x86 because its signedness is implementation-defined. Whenever the signed and unsigned readings differ, this tool shows both, because the mismatch is usually the thing you were looking for.

The bit grid

Every bit of the current value is shown with its position number, and clicking one flips it. The bases update immediately, which makes a few questions much easier to answer than by hand:

• Which bit is set in this flag value — click through them and read the positions.
• What is the mask for bits 4 and 7 — set those two and read the hex.
• What does setting the top bit do to a signed value — it turns it negative, visibly.
• Is this value a power of two — a power of two has exactly one bit set.

Bit 0 is the least significant bit and sits on the right, which is the universal convention and the reason the grid stays left-to-right even on a right-to-left page. Rows are eight bits wide so byte boundaries are visible at a glance.

Large numbers stay exact

JavaScript numbers are doubles, which hold integers exactly only up to 2^53 — about 9 quadrillion. A 64-bit value can exceed that, and a converter built on ordinary numbers will quietly round it, giving a hex string that looks plausible and is wrong in its last digits.

Everything here uses arbitrary-precision integers instead, so a full 64-bit value converts exactly. The arbitrary-precision width mode goes further and removes the limit entirely — useful for cryptographic values and large identifiers — but note that without a fixed width there is no two’s complement, so a negative number in that mode simply carries a minus sign in every base.