DevKitHub

Programming

Number Base Converter — Binary, Octal, Decimal, Hex

Enter a number in any base to see it in all the others. Values are converted exactly, so a 64-bit register dump comes back as the number you typed.

Converted — read as base 16

Decimal
3735928559
Hexadecimalbase 16
DEADBEEF
Octalbase 8
33653337357
Binarybase 2
11011110101011011011111011101111
Base 36
1ps9wxb
Binary grouped32 bits
1101 1110 1010 1101 1011 1110 1110 1111

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

Conversion runs on BigInt rather than on ordinary numbers, and that is not a detail. parseInt("FFFFFFFFFFFFFFFF", 16) returns 18446744073709552000 — a value that is not the number in the string, and not even odd. Anything past 2^53 is approximate as a double, and values past 2^53 are precisely what a base converter gets asked about: a register dump, a 64-bit mask, a Snowflake id, a hash fragment. BigInt is exact at any size, so the answer is the value that was typed rather than the nearest one a double can hold.

The base is inferred from the input. A 0x, 0b or 0o prefix is honoured, letters with no prefix are read as hexadecimal because that is how a value is pasted out of a debugger, and anything else is decimal. Underscores, spaces and commas are ignored, so a grouped literal copied out of source can be pasted as it is. The base can also be stated explicitly, in which case the inference is skipped entirely — necessary for a value like 1010, which is a valid number in every base.

For a negative value the two’s complement representation is shown at each width it fits in, which is what the number actually looks like in memory. This is the reason -1 reads as 0xFF in a byte, 0xFFFF in a 16-bit word and 0xFFFFFFFF in a 32-bit one: the same value, three different widths, and the source of a whole category of confusion when reading a hex dump or a bitmask.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

That is not a valid base-16 number.

xyz
Why:
Letters beyond F are not hexadecimal digits. Unprefixed letters are read as hex, so a word gets treated as a number and fails on the first letter out of range.
Fix:
Hexadecimal uses 0-9 and A-F. For a higher base, set the base explicitly — base 36 uses the whole alphabet.

The last few digits of a large number changed.

Why:
Almost every converter uses parseInt and Number, which are IEEE-754 doubles and stop being exact past 9007199254740991. A 64-bit value loses its low digits without any warning.
Fix:
Nothing to do here — this tool uses BigInt throughout. Elsewhere, use BigInt in JavaScript, or keep the value as a string.

1010 converted from the wrong base.

Why:
1010 is a valid number in binary, octal, decimal and hexadecimal, and they are four different values. With no prefix it is read as decimal.
Fix:
Prefix it — 0b1010 — or set the source base explicitly rather than relying on the inference.

Frequently asked questions

Can it handle numbers larger than 64 bits?
Yes, at any size. Conversion uses BigInt, which has no upper limit beyond available memory, so a 256-bit hash or a 30-digit decimal converts exactly.
Why does -1 show as 0xFFFFFFFF?
That is two's complement, the way computers represent negative integers. The value depends on the width: -1 is 0xFF in 8 bits, 0xFFFF in 16 and 0xFFFFFFFF in 32. All the widths the value fits in are shown together.
How does it know what base my input is in?
From a 0x, 0b or 0o prefix if there is one, otherwise hexadecimal if it contains letters and decimal if it does not. Set the base explicitly for anything ambiguous — 1010 is valid in every base and means something different in each.

Related tools

Last updated