Number Base Converter

Convert numbers between binary, octal, decimal, and hexadecimal

This converter shows one whole number in four bases at the same time. Type into any of the four fields — Binary (base 2), Octal (base 8), Decimal (base 10), or Hexadecimal (base 16) — and the other three rewrite themselves as you type. There is no convert button and no direction to pick: whichever field you last typed in is the source, and the rest are outputs. Each field has its own Copy button, so you can paste the exact representation you need straight into code, a config file, or a ticket.

Input is forgiving in the ways that matter when pasting out of a debugger or datasheet. A leading 0x, 0b, or 0o prefix is stripped automatically if you type it into the matching field, underscores and spaces used for digit grouping are ignored (so 1111_0000 and 1111 0000 both parse), and hex letters can be upper or lower case. A leading minus sign is accepted, so negative values convert too. Hex output is normalised to upper case. Values are parsed as arbitrary–precision integers, so a 128–bit value or a 64–bit register dump converts without the silent precision loss of tools built on floating–point numbers.

When the value is zero or positive, the tool also reports its bit length, the number of bytes needed to hold it, and the value written with an explicit 0x prefix. That bit length is the count of significant bits — the position of the highest set bit — not a padded width, which is exactly what you want when you are checking whether a value still fits in a field.

What this tool converts, and what it does not

This is a whole–number converter. It handles integers in bases 2, 8, 10, and 16, in any direction between them, including negative integers of any size. It does not accept fractions, exponent notation, or floating–point bit patterns, and it does not translate text characters into hex or binary. If you paste something that is not a valid digit string for the field you are typing in — a 2 in the binary field, a G in the hex field, an 8 in the octal field — that field turns red and tells you the value is not valid for that base rather than silently producing a wrong answer.

For byte–level work on text and files — a string shown as hex bytes with an ASCII column beside it — use the hex editor. The sections below cover text–to–hex and hex–to–text as concepts, because they are constantly confused with numeric base conversion.

Base conversion reference table

The same value written four ways. These are the values worth memorising, because they are the boundaries you keep meeting in real systems: byte limits, permission bits, and address ranges.

Hex to decimal

Paste the hex value into the Hexadecimal field and read the Decimal field. Doing it by hand is positional arithmetic: each hex digit is worth 16 times the one to its right. For 2F, that is 2 × 16 + 15 = 47. For 1A3: 1 × 256 + 10 × 16 + 3 = 419. The letters are the part people stumble on — A is 10, B is 11, C is 12, D is 13, E is 14, F is 15.

The common real–world versions of this conversion are reading a hex error or status code as a number, converting a hex colour channel (C8 is 200), and turning a hex byte count from a header into something you can compare against a decimal limit. Watch for hex values that are already decimal–looking: 0x10 is 16, not 10, and 0x100 is 256, not 100. If two systems disagree by a factor that feels arbitrary, this is usually why.

Decimal to hex

Type the number into the Decimal field and read the Hexadecimal field; the tool also shows it with an explicit 0x prefix in the details panel. By hand, divide repeatedly by 16 and read the remainders bottom to top: 419 ÷ 16 = 26 remainder 3; 26 ÷ 16 = 1 remainder 10 (A); 1 ÷ 16 = 0 remainder 1 — giving 1A3.

The practical trap is width. The tool prints the shortest correct hex string, so decimal 10 becomes A. If the destination expects a fixed width — a two–digit colour channel, a four–digit 16–bit register, an eight–digit 32–bit word — pad it yourself: 0A, 000A, 0000000A. Each byte is exactly two hex digits, so the Bytes readout tells you the width.

Hex to binary

Paste into the Hexadecimal field and read the Binary field. This is the one conversion you can reliably do in your head, because each hex digit maps to exactly four binary digits with no carrying between them:

• 0 = 0000, 1 = 0001, 2 = 0010, 3 = 0011
• 4 = 0100, 5 = 0101, 6 = 0110, 7 = 0111
• 8 = 1000, 9 = 1001, A = 1010, B = 1011
• C = 1100, D = 1101, E = 1110, F = 1111

So 0xC3 is 1100 0011 and 0xFF00 is 11111111 00000000. That nibble alignment is why hex is used for bit–level work: you can see which bits a mask sets without converting the whole number. The tool prints binary without leading zeros, so 0x0F comes back as 1111, not 00001111 — pad it to the register width before lining masks up.

Binary to decimal and binary to hex

Type the bit string into the Binary field — grouped with spaces or underscores if that is how you copied it — and read the other three fields. Going to hex, split the bits into groups of four from the right and map each group with the table above, padding the leftmost group with zeros: 110 0011 becomes 0110 0011 becomes 0x63. Going to decimal, add the place values of the set bits: 1100011 is 64 + 32 + 2 + 1 = 99.

Octal conversions

Octal groups bits in threes instead of fours, which is why Unix file permissions are written that way: 755 is 111 101 101, which reads directly as rwx for owner, r–x for group, r–x for others. Type 755 into the Octal field and you will see it is decimal 493 — a number that means nothing on its own, which is exactly why permissions are never quoted in decimal. Octal digits only run 0–7; if you paste a value containing an 8 or 9 the field flags it, and that usually means the value was decimal all along.

Negative numbers and two’s complement

Type -1 into the Decimal field and the tool shows -1 in every base. That is the mathematically correct answer: it converts the magnitude and keeps the sign. It is not what a 32–bit register holds. Hardware stores negative integers in two’s complement, where −1 in a 32–bit word is 0xFFFFFFFF and −1 in a byte is 0xFF. There is no single hex form of −1 — it depends entirely on the width you chose.

To go from a signed decimal to its two’s complement hex form by hand for a width of n bits: add the value to 2ⁿ, then convert the result. For −5 in 8 bits, 256 − 5 = 251, and 251 converts to FB. For −5 in 16 bits, 65536 − 5 = 65531, which is FFFB. You can do both steps here: work out the sum, type it into Decimal, read Hex.

Going the other way, the giveaway is the top bit. If a byte–width value has its high bit set (hex 80 through FF) and the field is documented as signed, it is negative: subtract 256 from the unsigned value. 0xFB is 251 unsigned, and 251 − 256 = −5. For a 16–bit field, subtract 65536; for 32–bit, subtract 4294967296. A value that suddenly reads as a huge positive number close to the maximum for its width — 4294967291, say — is almost always a small negative number being read as unsigned.

Byte width, zero padding, and bit length

Base conversion answers “what is this value”, not “how wide is the field”, and most conversion bugs live in that gap. A value with bit length 9 no longer fits in a byte, however small it looks in decimal.

• Hex digits per width: 2 for a byte, 4 for 16–bit, 8 for 32–bit, 16 for 64–bit. Always an even number for whole bytes.
• Pad on the left, never the right. 0x1F padded to 16 bits is 0x001F. Writing 0x1F00 multiplies the value by 256.
• Fixed–width formats care. MAC addresses, colour codes, checksums, and protocol fields are compared as strings in plenty of code paths, so 0F and F are not interchangeable there even though they are the same number.
• Binary output here is unpadded. Pad to 8, 16, or 32 bits yourself when comparing against a mask.

Why 0x, 0b, and 0o prefixes exist

Written on its own, 101 could be a hundred and one, or five in binary, or sixty–five in octal, or two hundred and fifty–seven in hex. Prefixes remove the ambiguity for compilers and for people: 0x marks hex, 0b marks binary, and 0o marks octal in modern languages. This tool accepts all three as optional input and strips them, so you can paste literals straight out of source code.

One legacy hazard is worth knowing: in C, C++, Java, and several older languages, a plain leading zero means octal. 017 is 15, not 17, and 0755 is 493. Python 3 rejects a bare leading zero and requires 0o, but the old rule still bites in config parsing wherever a zero–padded number meets a permissive parser. If a padded number is being interpreted strangely, test whether something is reading it as octal.

Text to binary, hex to ASCII, and other character conversions

These are separate operations from base conversion, and running them through a numeric converter is a reliable way to get a wrong answer. A number has one value in every base; text does not, because it must first be encoded into bytes, and the encoding is a choice.

Hex to ASCII and hex to string

A hex string like 48656C6C6F is not one enormous number to be converted — it is a sequence of bytes, two hex digits each: 48, 65, 6C, 6C, 6F. Each byte is then looked up as a character: H, e, l, l, o. The conversion is per byte, and the byte boundaries are what make it work, which is why an odd number of hex digits means something is already truncated or mis–copied.

ASCII to hex and text to binary

The reverse is the same process backwards: encode each character to its byte value, then write that byte as two hex digits or eight binary digits. A is 65 decimal, 0x41, 01000001. Lower–case a is 97, 0x61, 01100001 — exactly 32 more, which is the single bit that separates the cases in ASCII. A space is 32, 0x20. Digits 0 through 9 are 48 to 57, 0x30 to 0x39, so the character 7 is 0x37 and is not the number 7. Confusing those two is behind a large share of parsing bugs.

The UTF–8 caveat

ASCII only defines values 0–127, one byte per character. Real text is usually UTF–8, where anything outside that range takes two to four bytes. An accented letter, a curly quote pasted from a word processor, an emoji, or any non–Latin script becomes multiple bytes, so the character count and the byte count stop matching. If you are converting text to hex and the output is longer than two hex digits per visible character, that is multibyte UTF–8 working correctly — not an error. Splitting such a byte sequence at the wrong point produces the replacement character or mojibake downstream. For work like this, use a tool that shows bytes and characters side by side, such as the hex editor.

Common mistakes when converting bases

• Treating a hex string as a number. An identifier, hash, or MAC address that happens to be hex characters is a string of bytes with meaningful leading zeros. Converting it to decimal and back can silently drop them.
• Dropping leading zeros. The shortest correct output is not always the correct output for the destination format. Pad to the field width.
• Assuming a hex dump reads left to right. On little–endian machines — x86 and most ARM — a 32–bit value 0x12345678 sits in memory as the bytes 78 56 34 12. Reversing the byte order before converting is a separate step this tool does not perform; feed it the value, not the raw memory order, or reverse the byte pairs yourself first.
• Ignoring signedness. A huge positive value near the maximum for its width is usually a small negative number read as unsigned. Check the top bit.
• Missing the prefix. 10 in a hex context is 16. If two systems are off by a consistent multiple, check whether one side lost a 0x.
• Feeding a float in. This converter takes integers. The bit pattern of a floating–point number is a different problem, governed by IEEE–754 sign, exponent, and mantissa fields, not by base conversion of the printed value.
• Reading a permission or mode value as decimal. If 755 appears as 493 somewhere, one layer parsed it as octal and another as decimal.

When output looks wrong

Work through it in order. First, confirm the field you typed into matches the base of the value — typing a decimal number into the hex field is the single most common cause of a surprising result, and it will not error, because most decimal digit strings are valid hex. Second, check for an invalid digit: a red field with a message means that character cannot exist in that base. Third, check the width by looking at Bit length and Bytes, and pad the output if the destination needs a fixed size. Fourth, if the value came from memory or a packet capture, check the byte order. Fifth, if the value is meant to be signed, apply the two’s complement adjustment for its width rather than expecting the tool to guess a width it was never told.

Everything runs in your browser; values you type are not sent anywhere, which matters when the number came out of a production dump or a customer’s crash log.