Number Base Converter

Any base from 2 to 36, with real bit widths and a two’s-complement toggle — and exact past 2⁵³, where converters built on floating point quietly stop being right.

Runs 100% in your browser•Nothing is uploaded to a server•Free forever

Input

Number to convert

Read it as

Width

Signed (two's complement)

Extra base to show

Digit separators are fine — 1_000_000, 1111 0000 and 0xFF all read correctly. A leading - is a negative value, not a digit.

Every base at once

BIN

OCT

DEC

HEX

UNS

B36

Copied!

About this number base converter

Type a number, say what base it is already in, and every other base comes back at once — binary, octal, decimal, hexadecimal, and any base from 2 to 36 you pick as a sixth row. Digit separators are accepted on the way in, so a value pasted out of source code as 1_000_000, out of a register dump as 1111 0000, or out of a config file as 0xFF all read correctly without editing.

Why this one is worth trusting

Almost every converter on the web is built on JavaScript's Number, which is a 64-bit float. That is exact up to 9,007,199,254,740,991 and quietly wrong above it: ask one of those tools for the decimal value of 0x20000000000001 and you will usually get 9007199254740992, one short, with nothing to warn you. This page does the arithmetic in BigInt from end to end, so a 64-bit register value, a 128-bit UUID chunk or a 300-digit number all come back exact.

The second thing these tools get wrong is width. A number on its own has no width and no sign; a number in a register has both, and they change the answer. FFFFFFFF is 4,294,967,295 in a uint32_t and −1 in an int32_t, and both are correct — the bits are identical. Set a width here and you are told both readings, with the bit pattern shown as the register would hold it.

Set a width and the answer changes — on purpose

Leave the width on arbitrary precision and the converter behaves like mathematics: numbers are as big as you like, negatives keep their minus sign, nothing is masked. Choose 8, 16, 32 or 64 bits and it behaves like hardware instead. The value is written into a field that size, the binary, octal, hex and custom-base rows show the resulting bit pattern zero-padded to the full width, decimal shows the two's-complement reading if the signed box is ticked, and a separate unsigned row shows the same bits read the other way.

All-ones at each width, read both ways
Width	Bit pattern (hex)	Signed	Unsigned	Signed range
8-bit	`FF`	-1	255	-128 to 127
16-bit	`FFFF`	-1	65535	-32768 to 32767
32-bit	`FFFFFFFF`	-1	4294967295	-2147483648 to 2147483647
64-bit	`FFFFFFFFFFFFFFFF`	-1	18446744073709551615	-9223372036854775808 to 9223372036854775807

Two's complement is what makes that table work. Negating a number in two's complement is "flip every bit, then add one", which is why −1 is all ones at every width, why the negative range reaches one further from zero than the positive range, and why adding 1 to the largest positive value lands you on the most negative one instead of overflowing into an error. The converter tells you which of those happened: a pattern that fills the width, like FFFFFFFF in a signed 32-bit field, is a reinterpretation and nothing is lost, while a value that genuinely will not fit is called out as truncated.

Exactness past 2⁵³

Paste 9007199254740993 — one more than the largest integer a double can represent — and you get 20000000000001 back, not the even number one below it. That is the whole reason for the BigInt engine. Sixty-four-bit IDs, nanosecond timestamps, hashes and flag words all live above the float boundary, and they are exactly the values people paste into a base converter.

Going one direction only?

Each direction has its own page with its own reference table, because "hex to decimal" and "decimal to hex" are different jobs done by different people: hex to decimal, decimal to hex, binary to decimal, decimal to binary, hex to binary, binary to hex, text to binary, binary to text, text to hex and hex to text.