How this works
Every common base is a way to represent the same underlying integer using a different number of distinct digits. Decimal (base 10) uses 0 – 9. Binary (base 2) uses just 0 and 1, doubling place value with each position to the left: 1011 binary = 1×8 + 0×4 + 1×2 + 1×1 = 11 decimal. Hexadecimal (base 16) uses 0 – 9 then A – F for 10 – 15, with each position worth 16× the next; 0xFF = 15×16 + 15 = 255. Octal (base 8) is the rarely-used middle ground — once standard on PDP-style minicomputers, today mostly seen as Unix file permissions (chmod 755).
Why four bases? Because each fits a different real-world job. Binary is what the CPU runs. Hex is binary in a more typable form — each hex digit maps to exactly four binary digits (nibble), so 0xDEADBEEF is much easier to read than 11011110101011011011111011101111. Octal groups three bits per digit (handy when nine-bit bytes were a thing). Decimal is what humans count in. The calculator parses any one and emits the other three so you can sanity-check across all four without juggling Math.
Values above 2³¹ − 1 (2,147,483,647) are rejected because that's where signed 32-bit integer behaviour breaks down and bitwise operations in most languages start returning unexpected results.
The formula
The widget hands off to JavaScript's built-in parseInt(str, base) and Number.prototype.toString(base), so the heavy lifting is the language's standard library. Validation enforces the digit set per base before parsing, so non-binary characters in a binary input give a clean error instead of a silently truncated NaN.
Example calculation
- Type 255 with the Decimal button selected.
- Result row shows Binary 11111111 · Octal 377 · Decimal 255 · Hex FF.
- Click Hex and type DEADBEEF → Decimal 3,735,928,559. (Just under the 2³¹ cap.)
Frequently asked questions
Why is the upper limit 2³¹ − 1 and not 2⁶³?
JavaScript represents numbers as 64-bit floats and can safely handle integers up to 2⁵³ − 1 for ordinary arithmetic. But the moment you touch bitwise operations (& | ^ << >> ~), the runtime coerces operands to signed 32-bit integers, so anything above 2³¹ − 1 silently flips sign or wraps. We cap at 2³¹ − 1 here so the displayed bases stay consistent with what you'd see if you took the value into a bitwise expression in production code.
What about prefixes like 0x and 0b?
The widget rejects them — type just the digits and use the base button to set context. That's intentional: a prefix is a programming-language convention (C, Python, JavaScript), not a property of the number itself, and accepting prefixes inconsistently across the four bases makes the validator noisy. If you paste 0xFF, strip the 0x and select Hex.
Why is hex case-insensitive but displayed uppercase?
Lowercase hex (ff, deadbeef) and uppercase (FF, DEADBEEF) parse to the same integer; both are valid. The display normalises to uppercase because that's the dominant convention in finance, hardware and most documentation (Intel manuals, RFCs, RGB-pair colour syntax). Lowercase tends to win in some web-dev contexts — CSS, Node debug output — but it's a style choice rather than a correctness one. Copy-paste either form into the input and it works.