Binary to Decimal Converter

Somewhere between your keyboard and the screen, every letter you type gets flattened into a string of 1s and 0s. That is binary. Computers do not read English, they read voltage, on or off, and binary is the shorthand for that. This tool converts binary to decimal, hex, and octal instantly, but if you want to understand what happens when 1011 turns into 11, the explanation below takes about five minutes to work through properly.

What this tool does

The converter above takes a value in any of four number bases, binary, decimal, hexadecimal, or octal, and instantly shows the same value in the other three. Type into the binary field and the decimal, hex, and octal fields update at the same time, no submit button, no page reload. A step-by-step breakdown shows exactly which powers of 2 are being added to reach the final decimal number, which is useful for checking homework or verifying a manual calculation matches. A batch mode handles a whole list of binary values at once, which saves time when you are converting a set of flags or permission codes instead of a single number.

How to use it, step by step

1. Pick the base your starting value is in by clicking Binary, Decimal, Hex, or Octal at the top of the tool.
2. Type the value into the input field. Only valid characters for that base are accepted, so a binary field will reject anything other than 0 and 1.
3. The other three bases update immediately below the input, each with its own copy button.
4. Click "Show step-by-step breakdown" to see the bit position table, which lists every digit, its power of 2, and how much it contributes to the total.
5. For a list of values instead of one, switch to Batch convert, paste one binary number per line, and read the decimal and hex results in the table that appears.

Who this is for

Computer science students working through positional notation homework use it to check their manual conversions against a step-by-step breakdown instead of only getting a bare answer. Developers debugging bit flags, permission masks, or network subnet calculations use the hex and octal fields to move between representations without doing the math by hand. Networking students working through IP addressing and subnetting rely on the same binary-to-decimal math this tool automates. Anyone studying for a certification exam that covers number systems gets a fast way to verify practice problems.

How positional notation works

Decimal is the number system you grew up with. Ten digits, 0 through 9, and every position in a number is worth ten times the position to its right. In 213, the 2 is worth 200 because it sits two places to the left of the units column.

Binary works the same way, except the multiplier is 2 instead of 10. There are only two digits, 0 and 1, and each position is worth double the one before it. That is the entire idea. Once that clicks, converting binary to decimal stops being a trick and starts being arithmetic you can do in your head for short numbers.

The method, worked in full

Take the binary number 1011. Write it out and number the positions from right to left, starting at 0.

• Position 0 (rightmost): digit is 1, worth 2^0 = 1
• Position 1: digit is 1, worth 2^1 = 2
• Position 2: digit is 0, worth 2^2 = 4
• Position 3 (leftmost): digit is 1, worth 2^3 = 8

Add up only the positions where the digit is 1: 8 + 2 + 1 = 11. So 1011 in binary equals 11 in decimal. Every conversion follows this same pattern, no matter how long the binary string gets. Longer numbers mean more positions to add.

There is a second way to do this called the doubling method, and it is faster once you get used to it, especially for longer numbers. Start with a running total of 0. Read the binary number from left to right. For each digit, double your running total and add the digit. For 1011: start at 0, double and add 1 = 1, double and add 0 = 2, double and add 1 = 5, double and add 1 = 11. Same answer, different route. Some people find this easier to do without paper.

A couple of worked examples

Convert 10001 to decimal. Positions from the right: 1 (2^0=1), 0 (2^1=2), 0 (2^2=4), 0 (2^3=8), 1 (2^4=16). Add the 1s: 16 + 1 = 17.

Convert 11111111, an 8-bit number that shows up constantly in networking and color codes. Every position is a 1, so you are adding 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1, which comes to 255. That is why 255 is the maximum value of a single byte, and why you see it everywhere from RGB color values to IP address octets.

Going the other direction: decimal to binary

The converter handles this automatically, but the manual method explains why binary numbers look the way they do. The standard approach is repeated division by 2. Divide the decimal number by 2, write down the remainder (it will always be 0 or 1), then divide the quotient by 2 again, and keep going until you reach 0. Reading the remainders from bottom to top gives you the binary number.

Take 25. Divide by 2: quotient 12, remainder 1. Divide 12 by 2: quotient 6, remainder 0. Divide 6 by 2: quotient 3, remainder 0. Divide 3 by 2: quotient 1, remainder 1. Divide 1 by 2: quotient 0, remainder 1. Reading the remainders bottom to top gives 11001. Check it against the position method: 16 + 8 + 1 = 25. Matches.

This is also the exact algorithm most calculators and programming languages run internally when you call a base-conversion function. Python's bin(), JavaScript's Number.toString(2), they are all doing repeated division under the hood, much faster than you can do it on paper.

Bit width matters

A raw decimal number does not care how many digits it has. Binary, in computing contexts, usually does. An 8-bit value (a byte) can only represent 0 through 255, because there are exactly 256 possible combinations of 8 bits. A 16-bit value stretches that to 0 through 65,535. Try to store a number larger than a bit width allows and you get overflow, which is the source of more obscure bugs than most programmers want to admit.

This is why 255 keeps showing up: it is the ceiling of a single byte, and a single byte is the building block of almost everything, from RGB color channels to the individual sections of an IPv4 address. When you see a color like #FF5733, each pair of hex digits is one byte, one color channel, capped at 255 because that is the maximum an 8-bit value can hold. If you work with hex color values often, the Hex to RGB converter handles that specific conversion directly.

Binary versus hex versus octal

If binary is so fundamental, why do programmers spend so much time in hexadecimal instead? Raw binary is miserable to read. A 32-bit number in binary is 32 characters of 0s and 1s with no visual landmarks, and one misplaced digit changes the whole value without looking any different to a tired human eye.

Hexadecimal groups binary into chunks of 4 bits, and each chunk maps to a single hex digit, 0 through F. That turns a 32-bit binary number into 8 hex characters, which is why memory addresses, color codes, and MAC addresses are written in hex instead of raw binary. Octal does the same trick in groups of 3 bits and shows up mostly in older Unix file permission systems, the classic chmod 755 you still see in scripts today.

None of these differ from binary underneath. Hex and octal are more compact spellings of the same value. The converter above switches between all four instantly, so if you are debugging a color code, you can flip from hex straight to binary and see exactly which bits are on.

Signed numbers change the rules

Everything above assumes an unsigned binary number, one that only represents positive values. Computers also need to store negative numbers, and the common approach is called two's complement. In an 8-bit signed integer, the leftmost bit stops being worth 128 and instead flags the whole number as negative. To find a negative value, you flip every bit and add 1. Flip 00000101 (5) to get 11111010, add 1, and you get 11111011, which represents negative 5 in an 8-bit signed system.

This trips people up constantly, because the same bit pattern means something completely different depending on whether the system treats it as signed or unsigned. 11111111 is 255 unsigned, but negative 1 signed. If a plain binary-to-decimal conversion is giving you a number that seems way too large for the context, an unsigned interpretation of what should have been a signed value is usually the reason.

Where this shows up outside a computer science class

Binary is not academic trivia. If you have ever set file permissions on a server, that three-digit chmod number is binary in disguise, read, write, and execute, each represented by a single bit. Subnet masks in networking are binary math wearing a decimal costume. Color values in web design, RGB or hex, are binary underneath. Even the way computers store negative numbers, using two's complement, only makes sense once you understand plain binary first.

I used to think binary was one of those things you learn for an exam and never touch again. Then I spent an afternoon debugging a networking issue that turned out to be a subnet mask miscalculation, and suddenly all those position-and-power drills from years earlier were the only thing standing between me and a working VPN. It sticks around longer than people expect.

Mistakes that trip people up

The most common one is counting positions from the left instead of the right. Position 0 is always the rightmost digit, not the leftmost. Get that backwards and every power of 2 in your calculation is wrong.

The second is forgetting that a 0 digit still occupies a position, it contributes nothing to the sum. Skipping over zeros entirely, instead of not adding their value, throws off the position count for every digit after it.

The third, specific to programmers, is assuming binary numbers are unsigned by default. Once you introduce signed integers and two's complement, the leftmost bit can represent a negative sign rather than a normal place value, and the whole calculation changes. If you are working with signed 8, 16, or 32-bit integers, that is worth handling separately from a plain binary-to-decimal conversion.

Frequently asked questions