Number base converter

Most converters are wrong above 2^53, silently

This is the reason this page exists, and it is worth understanding because the failure is invisible.

JavaScript numbers are 64-bit floats, which represent integers exactly only up to 9,007,199,254,740,991 — 2^53 − 1. Past that, parseInt and toString(radix) still return an answer. It is just wrong in the low digits.

0xFFFFFFFFFFFFFFFF should be 18446744073709551615. A converter built on plain numbers returns 18446744073709552000.

That is exactly the input a developer arrives with: a 64-bit hash, a Twitter or Discord snowflake ID, a register dump, a file offset. Everything here uses BigInt, so the answer is exact at any size.

Prefixes and separators are accepted

Paste what you have. 0xDEAD_BEEF, 0b1010 1010, 0o755 and 1,234,567 all work — the prefix is stripped when it matches the base you selected, and underscores, spaces and commas are ignored.

Digits that do not belong to the base are refused by name rather than skipped. Silently dropping the g from 1g and reporting 1 is how a converter gives a confident wrong answer to a typo.

Two’s complement, and the signed-byte question

“What is 0xFF as a signed byte?” is a real question, and one a converter that only handles magnitudes cannot answer.

The same bits mean different numbers depending on how wide the container is and whether it is signed. 0xFF is 255 unsigned and −1 as a signed 8-bit value; 0xFFFF is 65535 or −1 depending on whether you are reading 16 bits.

Each width is shown where the value fits in it. If a number is too large for a byte, no 8-bit reading is offered, because there is not one.

Bases beyond 16

Any base from 2 to 36 works, using 0-9 then a-z. Base 36 is the densest form that survives being typed by a human, which is why short IDs and URL shorteners often use it.

Nothing is uploaded

Converted in this page.