base 10
base 16
base 8
base 2
Two's complement
Convert a number between binary, octal, decimal and hex at once: type in any box and the others follow. The Custom base box covers any base from 2 to 36, and the Two's complement panel shows negative numbers at 8, 16, 32 and 64 bits.
Decimal 255
Hexadecimal FF
Octal 377
Binary 1111 1111One hex digit is exactly four bits, so a byte is always two digits. That is why colors are written #RRGGBB, memory addresses are hex, and a SHA-256 hash is 64 characters.
Use binary for permission bits, bitmask flags and anything where individual bits matter. The Binary box groups digits in eights, one byte per group.
You mostly meet octal in Unix file permissions, where 755 is three groups of three bits: rwxr-xr-x. That history is also why a leading zero means octal in C, so 010 equals 8.
Base 36 uses the digits plus a to z. It shows up in short URLs and compact IDs, where you want the shortest string that is still safe to type.
Conversion uses BigInt, so large values
stay exact. JavaScript numbers lose precision above
253, and parseInt gives no error when
that happens. For example, ffffffffffffffff in hex
comes back from parseInt as 18446744073709552000,
which is off by 385. Paste a full SHA-256 in hex and the decimal
you get here is exact.
Two's complement is shown separately because it needs a fixed
width. The same negative number has a different bit pattern at
each width: -5 is FB as an 8-bit value and
FFFFFFFB as a 32-bit one. The tool lists all four
widths instead of guessing which one you meant, and marks a
value that does not fit as out of range.
parseInt("ff", 16); // 255
parseInt("11111111", 2); // 255
(255).toString(16); // "ff"
(255).toString(2); // "11111111"
// Above 2^53 this silently goes wrong:
parseInt("ffffffffffffffff", 16); // 18446744073709552000 <- not the answer
// BigInt is exact
BigInt("0xffffffffffffffff"); // 18446744073709551615n
BigInt("0b11111111"); // 255n
(255n).toString(16); // "ff"
// BigInt has no radix parser, so build one for arbitrary bases
const parseBig = (s, base) =>
[...s.toLowerCase()].reduce(
(acc, c) => acc * BigInt(base) + BigInt("0123456789abcdefghijklmnopqrstuvwxyz".indexOf(c)),
0n,
);The parseInt line above is why this tool uses BigInt. It returns a number that looks plausible and is wrong by 385.
int("ff", 16) # 255
int("11111111", 2) # 255
int("0o377", 0) # 255, base 0 reads the prefix
hex(255) # '0xff'
bin(255) # '0b11111111'
oct(255) # '0o377'
format(255, "08b") # '11111111', padded, no prefix
# Python integers are arbitrary precision, so this is simply correct
int("ffffffffffffffff", 16) # 18446744073709551615
# Two's complement at a fixed width
(-5 & 0xFF) # 251 -> 0xFB as a byte<?php
hexdec('ff'); // 255
bindec('11111111'); // 255
dechex(255); // 'ff'
decbin(255); // '11111111'
// Any base from 2 to 36
base_convert('ff', 16, 2); // '11111111'
// base_convert loses precision above PHP_INT_MAX.
// For big values use GMP or BCMath:
gmp_strval(gmp_init('ffffffffffffffff', 16), 10);
// '18446744073709551615'One hex digit is exactly four bits, which is why hex shows up wherever binary does: two digits per byte, six per color, 64 characters for a SHA-256 hash. Most developers meet octal in one place, Unix file permissions, where 755 is three groups of three bits spelling rwxr-xr-x. The same history is why a leading zero means octal in C, so 010 is 8.
This tool follows the specifications below. Read them when you need the exact normative wording, for example to settle an edge case between two implementations.
Binary, octal, decimal and hexadecimal side by side, plus any base from 2 to 36 in the Custom base field. Above 10 the digits continue into the alphabet, so base 16 uses a to f and base 36 runs to z.
Yes. Conversion uses BigInt, so a 256-bit hash or a 64-bit ID converts exactly. parseInt loses precision past 2^53 without any error: ffffffffffffffff comes back 385 too high, and that is how wrong IDs end up in a database.
A minus sign is carried through to every base. Two's complement needs a fixed width, so the tool shows the 8, 16, 32 and 64-bit patterns separately. For example, -5 is FB at 8 bits and FFFFFFFB at 32 bits.
No, whole numbers only. Many fractions have no exact representation in other bases, so a fractional converter has to round, and the tool rejects the input instead of rounding it without telling you.
Because 0.1 has no exact representation in binary, just as one third has none in decimal. In binary it is 0.000110011... with the 0011 repeating forever, so a 64-bit float stores the nearest value it can. This tool converts whole numbers only, so it cannot show that expansion.
To see the bytes behind text instead of a number, use text to binary. Hex colors are handled by the color converter, and epoch values by the Unix timestamp converter.