Index / Developer
Number Base Converter
Binary, octal, decimal, hex and every base up to 36, in either direction. The arithmetic is done on the digits themselves, so a 200-digit number converts exactly — nothing here is ever a floating-point number.
Input
Spaces, commas and underscores are ignored. A
leading minus is kept. An empty box is zero.
0x, 0b and 0o are recognised when detecting.
Only the two's complement panel uses this. The
conversions above it have no width at all.
Base 16
0
Bits
0
Bytes
0
The same number, in the bases people use
nothing groupedGrouped for reading
not for pastingTwo's complement
What it fits in
signed and unsigned
How the arithmetic is done, and what the digits mean
No floating point, and no
Digits are 0–9 then a–z, so base 36 is the largest base with a settled notation and is where this stops. Letters are read in either case; they are printed in lower case, except hexadecimal, which is printed in upper case because that is how it appears in most dumps.
Nothing in the base table is grouped. A number that exists to be pasted somewhere cannot have separators in it. The grouped forms are in their own section, and they are the ones not to copy.
The bit count is of the magnitude — the position of the highest set bit — and zero is counted as needing one bit to write down. The byte count is that rounded up to a multiple of eight.
Two's complement is where a width starts to matter. With no width a negative number has no binary form at all: −5 is a sign and a magnitude, not a bit pattern. At a chosen width it becomes 2w − 5, which is what a machine stores, and the same bits read as unsigned are a completely different number. Both readings are printed, because which one is meant is a property of the code, not of the bits.
A value too large for the width is refused rather than truncated. Silently keeping the low bits is what a C cast does; it is also how a wrong number gets into a screenshot. The panel says the value does not fit and shows how many bits it would need.
parseInt. A double stops
counting whole numbers at 9,007,199,254,740,993 — which is the
number this page starts with, and which JavaScript's own
parseInt reads as 9,007,199,254,740,992. Every conversion
here is long division on an array of digits, the way it is done on
paper, so the answer has as many digits as it needs and none of them are
wrong.
Digits are 0–9 then a–z, so base 36 is the largest base with a settled notation and is where this stops. Letters are read in either case; they are printed in lower case, except hexadecimal, which is printed in upper case because that is how it appears in most dumps.
Nothing in the base table is grouped. A number that exists to be pasted somewhere cannot have separators in it. The grouped forms are in their own section, and they are the ones not to copy.
The bit count is of the magnitude — the position of the highest set bit — and zero is counted as needing one bit to write down. The byte count is that rounded up to a multiple of eight.
Two's complement is where a width starts to matter. With no width a negative number has no binary form at all: −5 is a sign and a magnitude, not a bit pattern. At a chosen width it becomes 2w − 5, which is what a machine stores, and the same bits read as unsigned are a completely different number. Both readings are printed, because which one is meant is a property of the code, not of the bits.
A value too large for the width is refused rather than truncated. Silently keeping the low bits is what a C cast does; it is also how a wrong number gets into a screenshot. The panel says the value does not fit and shows how many bits it would need.