Number Base Converter
Convert between binary, octal, decimal and hexadecimal. Type in any of the four fields and the other three update on the spot. There is also an arbitrary-base panel for anything from base 2 to base 36. The maths runs in BigInt under the hood, so 64-bit register-sized values round-trip without losing precision.
Explain like I'm 5 (what even is this calculator?)
Numbers are just an idea. The way we write them on the page is a choice of alphabet. Decimal uses ten digits (0 to 9), binary uses two (0 and 1), hexadecimal uses sixteen (0 to 9, then a to f). The same quantity (255 apples in a barrel) can be written as 255, 11111111, or ff depending on which alphabet you pick. This page lets you type the quantity once and shows you what it looks like in all of them.
Convert
Prove it (show the working)
Type a value in any field to see the working.
The conversions all route through a single BigInt decimal value, so every base shown is the same number rendered with a different alphabet. The long-division trail repeats value ÷ base until the quotient hits zero, taking the remainder at each step as the next digit (read bottom-up). That is the algorithm BigInt.prototype.toString(base) uses internally for bases 2 to 36.
Useful? Save this calculator: press Ctrl + D to bookmark it.
When to reach for this
The everyday case is reading a value out of a debugger, a register dump, or a colour picker and wanting to see it in another base without firing up a programming REPL. RGB colours often arrive as hex (#ff8800); CSS sometimes wants decimal RGB. Permission masks on Unix come out in octal (755, 644); kernel messages quote them in decimal. A network packet capture might give you a port as hex; you want the decimal port number to grep your firewall log. A bitfield in a protocol spec is described in binary; you want the hex constant to put in your code. Type any of those into the right field here and the other three appear instantly.
The other case is teaching. The long-division trail in the prove-it panel walks through the algorithm one step at a time. If you are explaining to a junior why 255 is 0xff, having the working written out is more convincing than asking them to trust a black box.
Common mistakes
The single biggest pitfall is precision loss. JavaScript's normal Number type is a 64-bit IEEE-754 double, and integers stop being exact past 253 - 1. If you ever wrote parseInt('deadbeefcafebabe', 16) in your console you have already met the problem: the low bits get rounded off because the result will not fit in a double. This calculator works in BigInt from end to end, so values like 0xFFFFFFFFFFFFFFFF (264 - 1) come back exact. The safety note appears whenever you cross the threshold so you remember to use BigInt in any code that consumes the value.
The next pitfall is mixing alphabets. People sometimes type 0x at the start of a hex value out of habit, or a leading zero in front of an octal. Both confuse half the converters on the internet. This one wants the bare digits in the right field, no prefix, and rejects anything that is not a valid digit for that base. Pasting 0xff into the hex field will fail because x is not a hex digit; the bare ff is what you want.
The last common mistake is assuming all calculators handle case the same way. Some require uppercase hex, some require lowercase. This page accepts either and normalises the output to lowercase, partly because lowercase hex is the convention in modern web standards (CSS colours, SRI hashes, JWTs), and partly because mixed-case DeAdBeEf is harder to scan than deadbeef.
Why arbitrary bases
Most everyday work happens in 2, 8, 10 or 16, but the system generalises cleanly to any integer base from 2 up to 36 (the cap is set by the alphabet: ten numerals plus twenty-six letters). Base 32 turns up in Nix store hashes and TOTP secrets. Base 36 is a popular short-identifier scheme because it gives you the densest representation that survives a case-insensitive copy and paste. Base 12 (duodecimal) has a small but devoted following because 12 has more useful divisors than 10. The arbitrary-base panel handles all of those with the same BigInt machinery as the four standard bases.
Related calculators
Bases are one numeric encoding. These are the others.
Frequently asked questions
Why use BigInt instead of regular numbers?
JavaScript numbers are IEEE-754 doubles, which run out of integer precision at 253 - 1. A 64-bit register-sized value (anything wider than about 16 hex digits) starts to lose its low bits the moment you parse it as a normal Number. BigInt is the platform's arbitrary-precision integer type, so 0xDEADBEEFCAFEBABE round-trips through this converter without dropping a single bit. The page shows a small warning whenever your value goes past Number.MAX_SAFE_INTEGER, so you know the BigInt path is the one that matters.
Why does it reject characters like 2 in binary or g in hex?
Each base has a fixed alphabet: binary is 0 and 1, octal is 0 to 7, decimal is 0 to 9, hex is 0-9 and a-f. A 2 in a binary field is not a typo we can sensibly recover from, it is a different number system, so the converter flags it instead of guessing. Hex is normalised to lowercase on the way out so the four fields stay visually consistent.
What is the arbitrary-base panel for?
Sometimes you have a value in base 36 (short URLs, Crockford-style identifiers), base 32 (Nix store hashes), base 12 (timekeeping), or anything in between. The arbitrary-base panel takes any base from 2 to 36, parses your value with that alphabet, and shows the equivalent in all four standard bases. Same BigInt internals, same long-division trail in the prove-it panel.
Is this calculator only for positive whole numbers?
Yes. Negative numbers in binary need a separate decision about the encoding (sign-magnitude, two's complement at a fixed width, etc.) and there is no single right answer without knowing the target system. Fractional values are even messier across bases. The tool sticks to non-negative integers because that is what nearly every programmer base-conversion question is actually asking, and ambiguity in the result would make the tool less useful, not more.
Does it work offline?
Yes. The conversion runs entirely in your browser. No fetch, no server call, no third-party library. Disconnect your network and the page still converts.