Type in any row to convert from that base. Supports large integers via BigInt.
Four linked fields — binary, octal, decimal, hex — where editing any one instantly rewrites the other three. Parsing goes digit-by-digit into a BigInt, so there is no precision ceiling: values far past what a JavaScript double can hold convert exactly.
Exact past 2^53, where ordinary converters start rounding
JavaScript's Number type is only exact up to 9,007,199,254,740,991 (2^53 - 1). Converters built on parseInt and toString silently round above that, which is exactly the range where 64-bit database IDs, Snowflake IDs, and file offsets live. Here, 2^64 = 18446744073709551616 converts to hex 10000000000000000 with every digit intact, and you can go far larger; the only practical limit is how much you paste.
What each field accepts
Digits only, per base: the 0b/0o/0x prefixes are displayed as labels outside the input, so typing 0x1F into the hex field flags Invalid on the x. Hex accepts either letter case and outputs lowercase. A leading minus works in any field and the result is sign-magnitude: -5 in binary reads -101, not a string of ones. There is no fractional support — these are integer conversions only. An invalid keystroke marks just that field red without wiping the others, so you can backspace and continue.
One thing people ask
Why doesn't -1 show as 11111111 in binary?
Two's complement only exists at a fixed bit width: -1 is 11111111 in 8 bits but a different string in 16, 32, or 64. Since these are arbitrary-precision integers with no declared width, the display is sign-magnitude (-1 binary is -1). To read a two's-complement register value, add 2^width to the negative number first and convert that.
This converts a number between representations. Turning text into hex bytes is a different operation — that is the hex encoder — and Unix epoch values in any base are better read through the timestamp converter.