🔥 Binary Octal Decimal & Hex Guide (Conversions 2026)

The four bases you will meet most often

Binary has just two digits, so every position is a power of 2. For example, 1101 in binary means:

• 1 × 23 = 8
• 1 × 22 = 4
• 0 × 21 = 0
• 1 × 20 = 1

The total is 13 in decimal. The little ₂ in 1101₂ is sometimes used to show the base explicitly. In code, you'll often see prefixes like 0b for the same reason.

Octal uses powers of 8. Hexadecimal uses powers of 16. Hex needs more than ten symbols, so A through F represent 10 through 15. That means A is one more than 9, and F is the largest single hex digit.

One value, four representations

Here are a few values written in all four bases:

Don't treat these as four different numbers. They're just four ways to write the same quantity. If a program shows 0xFF, the 0x is telling you "hex," not changing the value - 0xFF still means 255 in decimal.

So when a conversion goes wrong, ask one thing first: did the underlying value change, or did you only misread the notation?

Convert binary, octal, or hex to decimal

Look at each digit, multiply it by the value of its position, and add everything up. For binary 1101₂:

1 × 23 + 1 × 22 + 0 × 21 + 1 × 20 = 8 + 4 + 0 + 1 = 13

For hexadecimal 2F₁₆, remember that F represents 15:

2 × 161 + 15 × 160 = 32 + 15 = 47

This works because it follows the definition of positional notation. It's also handy for checking what a program printed or tracing a value without guessing. Most mistakes come from assigning powers from the wrong end - the rightmost digit is always power zero.

Convert decimal to binary, octal, or hex

Divide the decimal number by the base you want. Write down the remainder each time. Then divide the quotient again. When the quotient hits zero, stop. Read the remainders in reverse (last remainder first).

Example: convert 255 to hexadecimal.

1. 255 ÷ 16 gives quotient 15, remainder 15.
2. 15 ÷ 16 gives quotient 0, remainder 15.
3. Read remainders backwards: 15, 15.
4. Hex digit for 15 is F, so 255 is FF in hexadecimal.

Same idea for converting 13 to binary:

1. 13 ÷ 2 gives quotient 6, remainder 1.
2. 6 ÷ 2 gives quotient 3, remainder 0.
3. 3 ÷ 2 gives quotient 1, remainder 1.
4. 1 ÷ 2 gives quotient 0, remainder 1.
5. Reverse the remainders: 1101.

So 13₁₀ = 1101₂. The steps aren't hard - but writing down the quotient and remainder helps you avoid the common slip of reading remainders in the order you generated them.

Convert between binary and octal or hexadecimal directly

When you go between binary and octal/hex, you can usually skip decimal. Group the binary digits from the right, then swap each group for its matching digit.

• For octal, group in chunks of 3 bits, because 23 = 8.
• For hexadecimal, group in chunks of 4 bits, because 24 = 16.

If the first group is short, add leading zeroes on the left. That doesn't change the value - just makes the grouping work.

Example: binary 11010110 grouped in threes becomes 011 010 110. Those groups are 3, 2, and 6, so the octal form is 326.

For hex, group the same binary in fours: 1101 0110. Those groups are D and 6, so the hex value is D6.

Going the other way is just as direct: replace each hex digit with its 4-bit binary form. D6 becomes 1101 0110, or 11010110 without spaces. This grouping approach is often the quickest way to sanity-check bit patterns.

Hex is a practical shorthand for bytes

One hexadecimal digit represents exactly four bits. A byte is eight bits, so one byte fits neatly into two hex digits: 00 through FF.

For example:

• 00000000₂ is 00₁₆ and 0 in decimal.
• 11111111₂ is FF₁₆ and 255 in decimal.
• 01000011₂ is 43₁₆ and 67 in decimal.

That's why you'll see hex in color values like #4338ca, in memory inspection tools, and in network or file-format documentation. It's compact, but it still makes the byte boundaries obvious.

You'll also see 0xFF in code. The 0x prefix means "this number is written in hexadecimal." It isn't part of the value. 0xFF is 255, which is the biggest number that fits in an unsigned eight-bit byte. This detail matters: those same 8 bits can represent a different number if the program treats them as signed.

Octal makes permission bits easier to read

Octal fits naturally when you're working with groups of three bits. A classic example is Unix-like file permissions, often set with something like chmod 755 filename.

Each octal digit corresponds to three permission bits. In the usual permission model, the bits mean (4), (2), and (1): read, write, and execute. Add them to get the combined permission you want:

• 7 = 4 + 2 + 1: read, write, execute
• 5 = 4 + 1: read, execute
• 0 = no permissions

In 755, the three digits apply in order: owner, group, and others. So the owner gets all three permissions, and group/others get read and execute but not write. The number stays short because each digit maps cleanly to one three-bit group.

It's worth learning this for the practical reason: if you need to double-check what chmod actually does for your system, look at the documentation and be careful when changing permissions on shared or production files.

Choose the representation that matches the task

A decent rule of thumb:

• Use decimal when the value is meant to be read as a normal quantity.
• Use binary when the bits themselves - masks, flags, layouts - are the point.
• Use octal when the problem naturally groups bits in threes, like Unix permissions.
• Use hexadecimal when you're inspecting bytes, addresses, or other bit-level data.

Not every codebase follows this. Some interfaces show bytes in decimal, and some tools pick formats for historical reasons. The goal isn't to force everything into hex - it's to recognize the representation and convert when that makes the data easier to reason about.

Prefixes and quick conversions

Common prefixes include 0b (binary), 0o (octal), and 0x (hexadecimal). For example, 0b1010, 0o12, 10, and 0xA all represent decimal 10 in languages that support those literals. Older tools and languages can use different conventions too - like a leading zero for octal - so don't assume syntax is universal.

In JavaScript, you can parse a string in a chosen base, then convert back to another base:

parseInt('ff', 16); // 255
(255).toString(2);  // '11111111'
(255).toString(8);  // '377'
(255).toString(16); // 'ff'

In Python, you can use built-in functions for common conversions:

int('ff', 16)  # 255
bin(255)       # '0b11111111'
oct(255)       # '0o377'
hex(255)       # '0xff'

Those prefixes in returned strings can help for context, but they might need formatting or stripping for a user interface or file format. For uppercase hex, for example, you can use formatting like format(255, 'X'), which returns FF.

A conversion is not always just a conversion

A base tells you how the digits map to a value. It doesn't tell you the width of the value, whether it's signed, or how an application will interpret it. Those details often explain why the result "doesn't look right."

For instance, the eight-bit pattern 11111111 is 255 if you treat it as unsigned. Under the common eight-bit two's-complement signed representation, it means -1. Nothing "changed" in the bits - only the interpretation changed because the type or signedness changed.

That's why negative numbers need extra attention. Many systems use two's complement for signed integers, but languages and APIs don't all display or convert negatives in exactly the same way. Before you convert, check the type, the bit width, and the language's rules. A generic base converter might show a minus sign, while a low-level operation might show a fixed-width bit pattern.

Other mistakes are simpler, but they happen a lot:

• Dropping the base indicator: 10 could mean ten in decimal or two in binary. Add a prefix or label if ambiguity matters.
• Reading remainders in the wrong direction: for decimal-to-base, you must reverse the remainder list.
• Forgetting hex letters: A through F mean 10 through 15, not punctuation.
• Ignoring leading zeroes in groups: padding on the left makes grouping easier and doesn't change the value.
• Confusing a number with text: 'ff' isn't automatically hex just because it looks like hex. You need to tell the parser the base.
• Assuming a byte is always unsigned: a byte is just 8 bits; the numeric range depends on interpretation.

If you're double-checking a conversion in a browser, a free number base converter can be a quick cross-check. For code that processes user input, validate and specify the base explicitly instead of relying on defaults.