Base Converter
Convert a number between binary, octal, decimal, hexadecimal, or any custom base from 2 to 36, with every field editable and synced live.
About the Base Converter
Every field here (binary, octal, decimal, hex, plus a custom base from 2 to 36) is independently editable, and typing a valid value in any one of them recalculates the rest instantly. Parsing from text to a number is hand-rolled digit by digit using JavaScript's BigInt type rather than parseInt, so values well past 2^53 still convert correctly instead of silently rounding, and a leading minus sign is supported in any field. An invalid digit for the current base (like a '9' typed into the binary field) shows a clear error instead of guessing at a wrong answer.
Why BigInt instead of JavaScript's regular Number type
JavaScript's regular numbers can only represent integers exactly up to 2^53 − 1 (9,007,199,254,740,991), beyond that, the standard double-precision floating point format used internally starts silently losing precision, meaning two genuinely different large integers can end up looking identical, or a conversion can quietly round to the wrong value with no error at all. parseInt("111...1", 2) on a long enough binary string would hit exactly this problem. BigInt is a separate JavaScript numeric type with no upper bound, it can represent integers of arbitrary size exactly, limited only by available memory, which is why this tool builds its own parser around BigInt arithmetic rather than reaching for the built-in, faster, but precision-limited parseInt.
The digit-by-digit parsing algorithm
Converting a string of digits in any base into a single integer value uses the same technique regardless of which base you're starting from, known as Horner's method: start with a running total of zero, and for each digit read left to right, multiply the running total by the base and add the new digit's value. value = value * radix + digit, repeated once per character, correctly reconstructs the positional value of the whole number by the time it reaches the last digit, this is the same underlying logic every base-conversion algorithm uses, whether it's built into a language's standard library or, as here, written by hand specifically so each digit can be validated against the current radix as it's processed.
Why the digit alphabet stops at base 36
The parser recognizes digits from the string "0123456789abcdefghijklmnopqrstuvwxyz", ten numeric digits followed by all twenty-six letters of the Latin alphabet, exactly 36 distinct single-character symbols. That's precisely why base 36 is the practical ceiling for this kind of converter: representing a base higher than 36 in plain text would require inventing additional single-character symbols beyond 0-9 and a-z, which is why base 36 (not some rounder number) is the conventional upper limit for text-based arbitrary-radix conversion tools.
A single stored value, not four fields cross-referencing each other
Internally, this tool keeps exactly one BigInt (or null when empty) as the current value, and every visible field, binary, octal, decimal, hex, and the custom base, is simply re-rendered from that one stored value whenever it changes. It would be tempting to instead have each field try to convert directly from whichever field was just edited, but centralizing on a single source of truth avoids any possibility of the displayed fields drifting out of sync with each other, there's only ever one place where the "real" value lives, and every other field is a pure display of it.
Why hex and octal exist as first-class options, not just binary and decimal
Hexadecimal is common in computing specifically because 16 is a power of 2, each hex digit maps cleanly onto exactly 4 bits, so two hex digits represent one full byte (like #FF for 255, the maximum value a byte can hold), which makes hex a compact, human-friendly way to write out binary data, memory addresses, and color codes without losing that clean bit-alignment. Octal historically served a similar role for 3-bit groupings and still shows up today in Unix file permission notation (chmod 755), where each digit represents a 3-bit read/write/execute permission set. Binary and decimal remain the two universal reference points, everything ultimately is binary at the hardware level, and decimal is how humans normally read numbers.
Frequently Asked Questions
Why does this converter use BigInt instead of JavaScript's normal Number type?
Regular JavaScript numbers lose precision beyond 2^53 - 1 (about 9 quadrillion), silently rounding large values without any error. BigInt has no upper bound and represents arbitrarily large integers exactly, which is essential for a base converter that shouldn't quietly corrupt very large numbers.
What algorithm does the parser use to convert digit strings into a value?
Horner's method: starting from zero, it multiplies the running total by the radix and adds each new digit's value, one character at a time, left to right. This correctly reconstructs the number's positional value and lets each digit be validated against the current base as it's processed.
Why is 36 the maximum base this tool supports?
The digit alphabet uses the ten numeric digits 0-9 plus all twenty-six letters a-z, exactly 36 distinct single-character symbols. Representing a base higher than 36 in plain text would require additional symbols beyond the standard alphanumeric set.
Why do all the fields stay in sync when I edit just one of them?
The tool keeps a single internal BigInt value as the source of truth, and every visible field is simply re-rendered from that one value whenever it changes, rather than fields converting directly from each other. This prevents the displayed fields from ever drifting out of sync.
Why does hexadecimal map so cleanly onto binary data?
16 is a power of 2, so each hex digit represents exactly 4 bits, meaning two hex digits represent one full byte. This clean bit-alignment is why hex is the standard compact notation for memory addresses, binary data, and color codes.
Can I convert negative numbers with this tool?
Yes, a leading plus or minus sign is recognized and stripped before parsing the digits, then reapplied to the resulting value, so negative numbers convert correctly across binary, octal, decimal, hex, and any custom base.