Number Base Converter

Every number system you have ever used rests on one idea: a digit's worth depends on where it sits. Write 10 and you have not written 'one and zero' but 'one ten and no units' — the 1 borrows its weight from its position. The base names the exchange rate between neighbouring positions. Base 2 pays out in powers of two, base 8 in powers of eight, base 10 in powers of ten, base 16 in powers of sixteen. Bases above 10 need more digits than the alphabet of arithmetic provides, so letters join in: in hexadecimal a is ten, and by base 36 the letter z stands for thirty-five.

Reading a value out of its base is therefore just multiplication and addition, one term per digit. Take 1010 in binary — the same digits that mean 'ten' in decimal:

Eight plus two is ten, so 1010 in base 2 and 10 in base 10 are the same value in two costumes. The reverse direction — producing the digits in the first place — is the same table read backwards: divide by the base, keep the remainder as the next digit, and continue with the quotient until it runs out. That loop is all any base converter does, in either direction, and it is why the four cards on this page can all update from one keystroke.

Dead beef is the classic hex constant — a deliberately friendly-looking value that has padded debug screens and test suites for decades — and it makes a tidy demonstration because it exercises letters and digits at once. Grouped display writes it dead beef: two bytes per group. To read it as a decimal number, put each digit on its position and multiply, exactly as the binary example did, with sixteen as the base:

The eight contributions sum to 3735928559 — that is the decimal card's answer, and it is the number the RGB dot-chaser of every 1990s demo scene was secretly writing. The conversion is lossless in both directions: feed 3735928559 back in on the decimal tab and the hexadecimal card returns dead beef again. Notice also what the table shows about length: four bytes of information, eight hex digits, and ten decimal digits. Hex stays close to the machine's own grouping, which is precisely why engineers write values this way and why the grouped toggle exists.

Computers store bits, humans chunk, and hexadecimal is the compromise both can keep. The binding constraint on the machine side is the byte: memory, files and network traffic are all addressed in units of 8 bits. The binding constraint on the human side is that a row of fifty binary digits cannot be read, compared or dictated over a call. Hex resolves the tension because its digits split the byte exactly — one hex digit carries 4 bits, so a byte is always two hex digits and nothing is ever left over. Decimal has no such alignment: 255 needs three digits where ff needs two, and the decimal digits of a large value say nothing about where its bytes begin and end.

That table is the entire translation layer between binary and hex, and it is small enough to memorise — sixteen rows, and only the last six are anything new. Once it is internalised, hex stops being a foreign notation and becomes binary with the redundancy removed: #ff0000 is eight switched-on bits followed by sixteen switched-off ones, 0x80 is a byte with only its top bit set, and a v4 UUID's 4 at position fourteen is four known bits, not a mystery character. Every hex value on this page can be checked against this table by eye, which is a quiet part of why the notation has outlived octal as the programmer's default.

Every number on this page is a JavaScript number, and JavaScript numbers are IEEE-754 doubles: 64 bits split into a sign, an exponent and a 53-bit fraction. When the value is an integer, those 53 fraction bits are the entire precision budget, which sets a hard frontier at 2^53 − 1 — 9007199254740991, given its own name, Number.MAX_SAFE_INTEGER. It is called safe because every integer up to it has a unique representation; past it, consecutive integers begin to share one.

The failure is worth seeing once, because it is silent. Ask a console for 9007199254740992 === 9007199254740993 and it answers true: the last binary digit of the larger value simply never got stored, and both constants collapsed into the same double. A converter that accepted such input would then print digits with total confidence — the leading digits correct, the tail invented — and nothing in the output would warn you. In hex the frontier sits at 1fffffffffffff, fourteen digits; in binary, fifty-three ones.

The guard is applied per digit rather than to the finished value, because the finished value is exactly where precision would already be lost: the tool checks the running total against the remaining digits before every multiply-and-add step, so an oversized input is caught at the first digit that would push it past the ceiling. For anything larger, JavaScript's BigInt type removes the ceiling entirely at the cost of leaving ordinary number arithmetic — a different tool with different rules, and the honest boundary of this one.