Number Base Converter

How to use the number base converter

Paste a value, tell the tool which base it is written in, and every other base appears at once. The conversion is exact at any size, because the arithmetic runs on BigInt rather than on ordinary numbers, and there is a copy button on each row so you can take just the form you need.

The reason all four bases appear together is that base questions are almost always comparisons. You are checking whether 0xFF and 255 are the same value, or which bits a mask actually sets, or whether a permission octet matches the binary you expected. Showing one answer at a time makes you do that comparison in your head.

Hexadecimal earns its place because 16 is 2 to the power of 4, so one hex digit is exactly four binary digits and the two notations line up column for column. FF is 1111 1111, and B4 is 1011 0100. Nothing has to be calculated, only looked up, which is why hex is the shorthand for binary everywhere.

Octal works the same way one rung down, since 8 is 2 to the power of 3 and one octal digit is exactly three bits. That is why Unix file permissions are octal: three bits for read, write and execute is one digit per user class, so 755 is 111 101 101 and reads straight off the number.

The same care applies to the input side. parseInt stops at the first character it does not recognise and returns whatever it managed to read, so parsing 12G4 as hexadecimal gives 18 rather than an error. This tool names the offending character instead, because a value with a typo in it is a question, not a number.

Why every colour on the web is written in hex

A screen colour is three independent channels, red, green and blue, and each one is stored in a single byte with 256 possible levels. One byte is exactly two hex digits, so three bytes is exactly six, and that is the whole explanation for the six-character colour codes CSS has used since the beginning.

Try that split in decimal and the reason becomes obvious. The same colour is 16746496, and there is no way to see the three channels in it without dividing twice. In hex you read the pairs straight off the string, which is why designers and developers both learned to think in FF and 88 rather than 255 and 136.

The three-digit shorthand follows from the same arithmetic. CSS expands #F80 to #FF8800 by doubling each digit, so it can only express the 16 levels per channel where both digits match. It is a convenience for round numbers rather than a compressed format, and it cannot describe 136 at all.

Alpha is simply a fourth byte on the end, so #FF8800CC adds an opacity of 204 out of 255. The ordering is the thing to watch, because some platforms and file formats put alpha first instead, and a colour that comes out inexplicably transparent is usually an ARGB value being read as RGBA.

The 1000 against 1024 problem, in one paragraph

Memory is addressed in powers of two, so 1024 rather than 1000 is the natural step, and early computing borrowed the metric kilo prefix for it anyway. That borrowing is the entire source of the confusion, because a kilobyte then meant 1024 bytes to a programmer and 1000 bytes to everyone who had ever used the prefix before.

The standard fix has existed since 1998 and is now IEC 80000-13: kibibyte, mebibyte and gibibyte for the binary multiples, leaving kilo, mega and giga to mean exactly what they mean everywhere else in science. Adoption is uneven, which is why a drive sold as 500 GB shows up as roughly 465 GiB once formatted.

The base arithmetic behind it is visible in this tool. 1024 is 400 in hex and takes 11 bits, 4096 is 1000 in hex and takes 13, and 65536 is 10000 in hex and takes 17. Every one of them is a clean round number in hex and an awkward one in decimal, which is the whole reason the binary sizes stuck.

The formula, worked line by line

A positional number system is one rule applied repeatedly: each digit is multiplied by the base raised to the power of its position, counting from zero on the right, and the results are added. Decimal is that rule with a base of 10, and every other base is the same rule with a different multiplier.

Conversion between two bases is therefore two passes rather than one clever step. Read the input into an exact magnitude using the source base, then write that magnitude out by repeatedly dividing by the target base and collecting the remainders. Nothing about the value changes in between, only its spelling.

value = sum of digit[i] x base^i, counting positions from zero on the right
to write in a base: divide repeatedly, collect remainders, read them bottom to top
digits above 9 continue into letters, so base 36 runs 0 to 9 then a to z
one hex digit = 4 bits because 16 = 2^4
one octal digit = 3 bits because 8 = 2^3

That nibble alignment only works because 16 is a power of two. Decimal is not, so there is no group of bits that corresponds to one decimal digit, and converting between decimal and binary genuinely requires arithmetic rather than a lookup. It is the reason hex exists as a notation at all.

The exactness is the other half of the story. IEEE 754 double precision, the format an ordinary JavaScript number uses, carries a 53-bit significand, so every integer up to 9007199254740991 is exact and beyond that the gaps start. The first casualty is 2 to the power of 53 plus 1, which cannot be represented and silently becomes 2 to the power of 53.

Base 36 is where the digit alphabet runs out, since 10 numerals plus 26 letters is 36 symbols and there is no agreed thirty-seventh. That is also why base 36 shows up in short identifiers: it packs the most value into each character that a case-insensitive alphanumeric string can carry.

Questions people ask