🔢 Binary, Decimal & Hex Converter
A binary decimal hex converter (and octal) with arbitrary precision, so 64-bit values stay exact. Invalid digits are rejected, not silently dropped.
Digits 0–9. Spaces and underscores are ignored, so you can paste 1111_0000.
- BinaryBase 2
- 1111 1111
- OctalBase 8
- 377
- DecimalBase 10
- 255
- HexadecimalBase 16
- 0xFF
Needs 8 bits — it fits in 8-bit byte.
What Binary, Decimal & Hex Converter Does
Every number base holds the same value and only the notation changes. 255, 11111111, FF and 377 are one number written four ways, and converting between them is mechanical — which is why the interesting part of a base converter is not the conversion but what it does when something goes wrong.
Most converters are built on JavaScript's parseInt, and parseInt is permissive by design: it reads valid digits until it meets one it does not recognize, then stops and returns what it has. Type 1012 into a binary field and it returns 5, having quietly discarded the 2. There is no error, no warning, and the answer looks entirely reasonable. This one checks every digit against the base first and tells you which character is the problem.
The second failure is quieter still. JavaScript numbers are double-precision floats, exact only up to 2⁵³ − 1. A 64-bit hex value — a memory address, a hash fragment, a database identifier, exactly the things people paste into a base converter — exceeds that, and the low digits start coming back wrong. FFFFFFFFFFFFFFFF converts to 18,446,744,073,709,552,000 in most tools; the real answer ends 551,615. This one uses arbitrary-precision integers, so the digits are right however long the number.
Beyond that: binary is shown in groups of four and hex in byte pairs, because that is how they are actually read, and the bit count tells you which register width the value fits.
How to Use Binary, Decimal & Hex Converter
- Pick the base you are typing in
- Enter the value — spaces and underscores are ignored, so you can paste 1111_0000
- All four bases update at once, with binary grouped in nibbles and hex in bytes
- Check the bit count to see whether the value fits in 8, 16, 32 or 64 bits
Formula Used by Binary, Decimal & Hex Converter
What a base actually means
value = Σ digit × baseᵖᵒˢⁱᵗⁱᵒⁿ, counting positions from zero on the right
- Base
- How many distinct digits exist — 2, 8, 10 or 16
- Position
- Each step left multiplies by the base
Worked example
Binary 11111111
- 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1
- Every position is filled
Result: 255 — which is why one byte tops out there
Binary to hex without passing through decimal
Group the bits in fours from the right; each group is one hex digit
- Why fours
- 16 = 2⁴, so four bits express exactly one hex digit
- Octal
- Same trick in threes, because 8 = 2³
Worked example
Binary 11011110
- Split: 1101 | 1110
- 1101 = 13 = D
- 1110 = 14 = E
Result: DE — no decimal arithmetic needed at any point
Where the precision runs out
A JavaScript number is exact only to 2⁵³ − 1 = 9,007,199,254,740,991
- Above that
- Values are rounded to the nearest representable double
- The fix
- Arbitrary-precision integers, which have no such ceiling
Worked example
Hex FFFFFFFFFFFFFFFF, the largest 64-bit value
- With parseInt: 18,446,744,073,709,552,000
- Exact: 18,446,744,073,709,551,615
Result: Wrong by 385, with nothing on screen to indicate it
The same values in four bases
Note how the hex column tracks bytes exactly — every two hex digits is one byte, and every four binary digits is one hex digit.
| Decimal | Binary | Octal | Hex | Why it matters |
|---|---|---|---|---|
| 0 | 0000 | 0 | 0 | Empty byte |
| 8 | 1000 | 10 | 8 | A single bit set |
| 10 | 1010 | 12 | 0A | Where hex letters begin |
| 15 | 1111 | 17 | 0F | One full nibble |
| 16 | 0001 0000 | 20 | 10 | Hex rolls over |
| 64 | 0100 0000 | 100 | 40 | @ in ASCII |
| 127 | 0111 1111 | 177 | 7F | Largest signed byte |
| 128 | 1000 0000 | 200 | 80 | High bit set |
| 255 | 1111 1111 | 377 | FF | Largest byte |
| 256 | 0001 0000 0000 | 400 | 01 00 | Needs a second byte |
| 65535 | 1111 1111 1111 1111 | 177777 | FFFF | Largest 16-bit value |
How far each width reaches
The bit count in the result tells you which of these your value fits in — the practical question behind most base conversions.
| Width | Unsigned range | Largest value in hex | Typical use |
|---|---|---|---|
| 8 bits | 0 – 255 | FF | One byte, an ASCII character, a color channel |
| 16 bits | 0 – 65,535 | FFFF | Port numbers, older integers, Unicode BMP |
| 32 bits | 0 – 4,294,967,295 | FFFFFFFF | IPv4 addresses, standard integers, RGBA |
| 53 bits | 0 – 9,007,199,254,740,991 | 1FFFFFFFFFFFFF | The limit of an exact JavaScript number |
| 64 bits | 0 – 18,446,744,073,709,551,615 | FFFFFFFFFFFFFFFF | Memory addresses, database IDs, timestamps |
Prefixes, and one that causes bugs
Prefixes exist because the digits alone do not say which base they are in. The leading zero is the dangerous one.
| Prefix | Base | Example | Equals |
|---|---|---|---|
| 0b | Binary | 0b1010 | 10 |
| 0o | Octal (modern) | 0o755 | 493 |
| 0 | Octal (C tradition) | 0755 | 493 — not 755 |
| 0x | Hexadecimal | 0xFF | 255 |
| # | Hex, in CSS colors | #FF0000 | Red |
| none | Decimal | 755 | 755 |
How to Read Your Result
A silently wrong answer is worse than an error
The parseInt behavior is the reason this tool was rewritten. A converter that rejects "1012" as invalid binary costs you two seconds. A converter that returns 5 costs you however long it takes to notice the downstream problem, and it may never be traced back. This is a general principle worth applying to any tool that accepts free text: check whether it validates, or whether it merely does its best with whatever it is given.
Why hex won and octal mostly lost
Both compress binary, but hex compresses it in the unit computers actually use. One byte is exactly two hex digits, so a byte value is always a clean pair and a 32-bit word is always eight characters. Octal needs three bits per digit, which does not divide into eight, so a byte takes two and two-thirds octal digits and the boundaries never line up. Octal survives mainly in Unix file permissions, where three bits per digit happens to match the read/write/execute triple exactly.
The leading-zero trap
In C and languages that copied its syntax, a number written with a leading zero is octal. So 0755 is 493 and 0700 is 448 — and 0900 is a syntax error, because 9 is not an octal digit. This has caused real bugs in date handling, where a zero-padded month like 08 was parsed as octal and rejected. Modern JavaScript disallows it in strict mode and Python 3 requires the explicit 0o, but the pattern persists in configuration files and older code.
Reading binary in nibbles
A run of sixteen ones is unreadable; 1111 1111 1111 1111 is immediately four hex F characters. Grouping in fours is not decoration — it is the mechanism that makes binary-to-hex a lookup rather than a calculation, and it is how bit patterns are written in datasheets, protocol specifications and register documentation. Hex grouped in pairs does the same job one level up, showing you the byte boundaries directly.
Bases carry no information about signedness
The binary pattern 1111 1111 is 255 if the byte is unsigned and −1 if it is a signed two's-complement byte. Nothing in the digits themselves says which, so a converter cannot tell you: the interpretation lives in the type, not the value. That is why negative numbers are absent here rather than guessed at, and why the bit-width readout is the useful output — knowing that a value needs 9 bits tells you it will not fit in a byte regardless of how you interpret the sign.
Where you meet each base in practice
Hex turns up wherever bytes are shown directly: CSS colors, MAC addresses, memory addresses, hashes, Unicode code points. Binary appears in permissions masks, network masks, bit flags and hardware registers. Octal is almost entirely Unix file modes. Decimal is for humans. Most conversion work is really translation between a human-facing figure and a machine-facing one, which is why having all four visible at once is more useful than a single-direction converter.
Limitations & Accuracy Notes
- Only non-negative integers are supported. Negative values depend on the representation and register width, and fractional values in binary raise separate rounding questions.
- Bases are limited to 2, 8, 10 and 16. Other bases such as 32 and 36 are used in encoding schemes but are outside what this tool converts.
- Values are exact at any length because arbitrary-precision integers are used, but extremely long inputs will slow the display down before they cause any inaccuracy.
- Spaces and underscores in the input are ignored as formatting. If they are meaningful in your data, strip them yourself before converting.
- The bit count describes the value, not a type. A number needing 9 bits will not fit in a byte, but nothing here knows what width your program actually uses.
Frequently Asked Questions
Why do other converters give a wrong answer for invalid input?
Why does a 64-bit hex value come out wrong elsewhere?
How do I convert binary to hex without going through decimal?
Why is hexadecimal used so much in computing?
What does the 0x or 0b prefix mean?
Can it handle negative numbers?
References & Further Reading
- MDN — BigInt — The arbitrary-precision integer type used here, and why it is required above the double-precision safe-integer limit
- MDN — Number.MAX_SAFE_INTEGER — Documents the 9,007,199,254,740,991 ceiling and why BigInt is required above it
- MDN — parseInt — Documents the permissive parsing behavior that makes parseInt("1012", 2) return 5 rather than an error