Number Base Converter: Binary, Hex, Decimal, Any Base

The 64-bit test most converters fail

A JavaScript Number is an IEEE 754 double. It has 53 bits of significand, so it represents every integer up to 9,007,199,254,740,991 perfectly and then starts skipping. Above that boundary the nearest representable value is used silently. That is fine for prices and counters and catastrophic for the things people actually paste into a base converter: 64-bit database keys, Discord and Twitter snowflake IDs, hashes, memory addresses, register dumps.

Try these three in any converter you are considering. If it returns the right-hand column, its arithmetic is running through a float and you cannot trust it with anything wide.

The middle column is what this page returns. The third row is the smallest possible demonstration: 9,007,199,254,740,993 is 2⁵³ + 1, the very first integer a double cannot hold, and it quietly becomes its even neighbour. Strictly, the double behind the first row holds 2⁶⁴ and JavaScript prints the shortest decimal that round-trips to it, which is why you see a run of zeros where real digits should be — a useful tell that a value has been through a float.

Why bytes are written in hex and never in decimal

Sixteen is 2⁴, so one hexadecimal digit is exactly four bits and two hex digits are exactly one byte. That is the whole reason hex won. Converting hex to binary needs no arithmetic at all: swap each digit for its four-bit group and stop. 0xCD is 1100 1101, and you can read it back digit by digit without carrying anything. Decimal has no such alignment — 10 is not a power of two, so the digit boundaries and the bit boundaries never line up, and 205 tells you nothing about which bits are set.

Octal has the same property with three bits per digit, which is why Unix file permissions are octal: 755 is 111 101 101, three groups of read-write-execute, one group per digit. It fits three-bit fields perfectly and eight-bit bytes badly, which is why it survives in permissions and almost nowhere else. This is also the reason a leading 0 means octal in C: a habit from an era when word sizes were multiples of three.

The table below is the set of values worth memorising. Once you know the boundaries at 15, 255 and 65,535, most bit-twiddling stops requiring a calculator.

Hex is shown uppercase here for legibility; the tool has a case toggle, since Unix tooling tends to emit lowercase and Windows and older documentation tend to emit uppercase. The value is identical either way.

The same eight bits are 205 or −51

11001101 does not have a value. It has two, and which one you get depends entirely on how the surrounding code declared the variable. Read as an unsigned byte it is 205. Read as a signed byte in two’s complement it is −51. Nothing in the bits distinguishes the two cases — the type does, and a mismatched type is why a sensor reading or a byte from a network packet sometimes arrives as a large positive number where a small negative one was expected.

Two’s complement is the near-universal way signed integers are stored. The top bit carries a negative weight instead of a positive one: in a byte it is worth −128 rather than +128, and the remaining bits add as usual. So 11001101 is −128 + 64 + 8 + 4 + 1 = −51. Three consequences fall out of that one rule:

• Addition needs no special case. The same adder circuit handles signed and unsigned values, which is precisely why this representation beat sign-and-magnitude.
• −1 is all ones at every width: 0xFF, 0xFFFF, 0xFFFFFFFF. That is why an error return of −1 shows up in a hex dump as a solid run of F.
• The range is lopsided. A signed byte runs −128 to 127, not −127 to 127 — there is one more negative value than positive, and negating the most negative number overflows back to itself.

The two’s complement panel in the tool shows all of this at once: enter any value and you get its bit pattern, its unsigned reading and its signed reading at 8, 16, 32 and 64 bits, with a marker on the widths it does not fit.

Two right shifts that look identical and are not

An arithmetic right shift copies the sign bit back in as it shifts, so a negative number stays negative and the operation keeps behaving like division by two. A logical right shift feeds in zeros, so the sign bit is destroyed and a negative value becomes a large positive one. Both are written with angle brackets, both compile, and neither raises an error. Take −8 in a single byte:

Which operator gives you which depends on the language. In C and C++ the shift is chosen by the operand type: >> on a signed int is arithmetic, on an unsigned int it is logical, so changing a declaration from int to unsigned silently changes the behaviour of code you did not touch. Java and JavaScript spell them differently — >> is arithmetic, >>> is logical — which is safer, though JavaScript then forces both operands through 32-bit integers first, so bitwise operators there quietly truncate anything wider. Rust picks by type like C; Python has only the arithmetic shift, because its integers are unbounded and have no sign bit to lose.

Left shift has no such ambiguity, but it has its own trap: bits pushed past the top of the register are discarded with no signal at all. In the bitwise playground above, set the width to 8 bits and left-shift 0x80 by one to watch a value become zero. The playground evaluates every operation inside the width you choose, exactly as a real register would, rather than in arbitrary precision.

Integer widths, and where a value stops fitting

Overflow is not an exotic failure; it is what happens the moment a value needs one more bit than its type has. Keeping these four rows in your head prevents most of it.

The C type names are the common cases, not a guarantee: the C standard fixes minimum sizes rather than exact ones, so int and long genuinely differ between platforms. Use the fixed-width names — int32_t, uint64_t— when the width matters.

One limitation worth stating plainly: the conversion itself has no upper bound, but the two’s complement panel is defined only at these four widths. Odd widths — a 12-bit ADC reading, a 24-bit colour value, a 7-bit field in a protocol header — are not modelled, and the panel will simply report that the value does not fit. There is no fractional or floating-point support either: this converts integers only, so 3.5 is rejected rather than silently truncated to 3.

Everything runs in your browser. Nothing is uploaded, there are no accounts and nothing is saved, so pasting an internal identifier or a fragment of a key is safe. If you are decoding data rather than numbers, the Base64 encoder and decoder is the companion tool, and how Base64 encoding works covers the same bits-into-digits idea at a different group size.

Frequently asked questions