Bases are notation, not arithmetic
255, FF and 11111111 are the same quantity written three ways. What changes is the size of a digit position: base 10 counts in powers of ten, base 16 in powers of sixteen, base 2 in powers of two. Because 16 is 24, one hex digit maps onto exactly four binary digits with no carry between them, and because 8 is 23, one octal digit maps onto exactly three. That clean alignment is the entire reason hex exists in programming: reading 0xDEADBEEF is possible and reading the same 32 bits as ones and zeros is not.
Octal survives mostly through Unix file permissions, where three bits per digit happens to match read-write-execute perfectly, and in a few older systems where machine words came in multiples of three bits. Base 36 uses 0-9 then a-z and is the densest form that stays alphanumeric and case-insensitive, which is why it turns up in short URLs and license keys.
Negative numbers are a width, not a sign character
Hardware does not store a minus sign. In a fixed number of bits, −x is represented as 2n − x, which is called two's complement and has the useful property that ordinary binary addition works on signed and unsigned values identically. In eight bits, −1 is 11111111 and −128 is 10000000. The top bit ends up as one for every negative value, so it reads as a sign bit, but that is a consequence of the scheme rather than its definition.
The practical consequence is that a bit pattern has no meaning until you decide how to read it. 0xFF is 255 as an unsigned byte and −1 as a signed one. Change the word size selector above and watch the same negative value grow more leading ones — that is sign extension, the reason a negative int assigned to a long keeps its value while a negative value reinterpreted as unsigned becomes enormous. The classic version of this bug is a length or size field that goes briefly negative and is then used as an unsigned count.
The 2^53 wall
JavaScript's Number is a double, which represents integers exactly only up to 253 − 1 — about 9.007 quadrillion. Past that, values round to the nearest representable double and the low digits silently change. A 64-bit database ID, a Twitter-style snowflake, a hash fragment, a nanosecond timestamp: all of them exceed it, and all of them come back subtly wrong from parseInt or JSON.parse. The symptom is two distinct records that suddenly have the same ID, usually in production, usually months after the code shipped.
The fix is to keep such values as strings across the wire and as BigInt in arithmetic. This converter uses BigInt throughout, so a 200-digit input converts exactly and comes back exactly.
Why fractions are refused
Base conversion of an integer is exact by definition — every integer has one finite representation in every base. Fractions do not. One tenth is finite in base 10 and infinitely repeating in base 2, the same way one third repeats in base 10. A machine storing 0.1 as a double stores the nearest double, which is 0.1000000000000000055511151231257827, and that is why 0.1 + 0.2 does not equal 0.3.
Decoding a float is a genuinely different operation: you split the bits into a sign, an exponent with a bias, and a significand with an implied leading one, and reassemble. Presenting it as though it were a base conversion would teach the wrong model, so this tool declines the input and says why. If you need to see what a particular double looks like in memory, that calls for a dedicated IEEE 754 decoder.
Questions people ask
Does it accept 0x and 0b prefixes?
Yes, and they win over the base selector, so pasting 0xFF while the selector still says decimal gives 255 rather than an error. 0o marks octal in the same way. Separators are stripped before parsing, so 1_000_000, 1,000,000 and 1 000 000 all read as one million, and 0xDEAD_BEEF works as written.
What is base 36 used for?
Compact identifiers. Ten digits plus twenty-six letters gives the shortest representation that survives a case-insensitive system and a double-click selection, so it appears in URL shorteners, license keys and some database ID encodings. Base 62 is denser but needs case sensitivity, and base 58 exists specifically to drop the characters that look alike — 0, O, I and l — which matters when a human has to retype one.
I need lowercase hex.
Copy the value and lowercase it; hex digits carry no meaning in their case. The uppercase convention here is the one C, Java and most debuggers print by default. Be aware that a few contexts do care about the surrounding case, MAC address formats and some checksum encodings among them, but the digits themselves never do.
Why does the same bit pattern show two different decimal values?
Because you are looking at the signed and unsigned reading of the same bits, and both are correct. Nothing in the pattern says which one is meant — that lives in the type declaration, and if two pieces of code disagree about it, the bits pass between them unchanged while the meaning flips. That is precisely how a 3-billion-byte length ends up as a negative number, and why the tool prints both readings whenever a value sits in the range where they differ.