Binary, decimal, hex and octal converter
This converter translates whole numbers between binary (base 2), decimal (base 10), hexadecimal (base 16) and octal (base 8), and it keeps every digit exact no matter how long the number gets. Alongside each conversion it reports how many bits and bytes the value needs and shows the hexadecimal grouped into bytes. That makes it useful for checking memory addresses, hash values, cryptographic keys, bit flags and any integer too large for an ordinary calculator.
How to use it
- Start with the whole number in the base you already have: binary, decimal, hexadecimal or octal.
- Enter it in the tool above using only the digits valid for that base: 0 and 1 for binary, 0 to 7 for octal, 0 to 9 for decimal, and 0 to 9 plus A to F for hexadecimal.
- Read the equivalent value in the other three bases.
- Check the bit count and byte count to see how much storage the number occupies.
- Use the hex byte view when you need the value as a sequence of bytes, for example to compare it against a hex dump or a protocol specification.
The tool works on whole numbers only. It does not convert fractions or floating point values, encode text as ASCII or UTF-8, or perform arithmetic between numbers. It does not apply fixed-width two’s complement interpretation, so hexadecimal FF is read as 255, not as -1.
How base conversion, bit counts and byte views work
Every base on this page uses positional notation. A digit’s value is the digit multiplied by the base raised to the power of its position, counting from zero on the right. The decimal number 1750 means 1×10³ + 7×10² + 5×10¹ + 0×10⁰. The octal number 1750 means 1×8³ + 7×8² + 5×8¹ + 0×8⁰, which equals 1000 in decimal.
Hexadecimal and octal are popular in computing because they map cleanly onto binary. One hexadecimal digit always stands for exactly 4 bits, and one octal digit for exactly 3 bits. Here is the decimal value 1000 in each base:
| Base | Representation |
|---|---|
| Decimal | 1000 |
| Binary | 1111101000 |
| Hexadecimal | 3E8 |
| Octal | 1750 |
Split the binary from the right into groups of four (11 1110 1000) and you read off 3, E, 8. Split it into groups of three (1 111 101 000) and you get 1, 7, 5, 0.
Bit count is the number of binary digits needed to write the value without leading zeros. For any positive integer n, that is ⌊log₂ n⌋ + 1. The value 1000 needs 10 bits, because 2⁹ = 512 ≤ 1000 < 1024 = 2¹⁰.
Byte count is the bit count divided by 8 and rounded up, since storage comes in whole 8-bit bytes. Ten bits need 2 bytes.
The hex byte view pads the hexadecimal on the left to a whole number of bytes and splits it into pairs of digits, most significant byte first (big-endian order). So 3E8 becomes 03 E8. Keep in mind that many processors, including x86 and most ARM systems, store multi-byte integers in little-endian order. If you are comparing against raw memory, the bytes may appear reversed there.
Why “any size” matters. Standard double-precision floating point, used by JavaScript numbers and most spreadsheets, can only represent integers exactly up to 2⁵³ − 1, which is 9,007,199,254,740,991. Above that, digits get silently rounded. This tool uses arbitrary-precision integers instead, so a value such as 2⁶⁴ − 1 (18,446,744,073,709,551,615) converts exactly to FFFFFFFFFFFFFFFF, with 64 bits and 8 bytes. Add one and you get 2⁶⁴, hexadecimal 1 followed by sixteen zeros, which needs 65 bits and therefore 9 bytes.
FAQ
Why does the byte view add a leading zero?
Bytes are always two hexadecimal digits wide. When a value has an odd number of hex digits, like 3E8, a zero goes on the front so every byte is complete. The padding changes the layout but not the value.
Are uppercase and lowercase hex letters different?
No. The letters A to F stand for the values 10 to 15, and case has no effect on what the number means. 3e8 and 3E8 are the same value, 1000 in decimal.
Can it convert numbers with a decimal point?
No. The tool handles whole numbers only. Fractions and floating point formats such as IEEE 754 follow different rules, and this page does not cover them.
Why not just use a spreadsheet or calculator?
Most of them lose exactness on large integers. Excel keeps only 15 significant digits, and its DEC2BIN function accepts only values from -512 to 511. For 128-bit identifiers, 256-bit keys or long hash outputs, you need an arbitrary-precision converter like this one to get every digit right.