Number Base Converter: Binary, Octal, Decimal, and Hex Explained

Every number you have ever read aloud is written in base 10: ten digits, 0 through 9, with each position worth ten times the one to its right. Computers do not think that way. They count in base 2, store addresses in base 16, and occasionally hand you a base 8 file permission. Knowing how to move a value between these number bases — and why each base exists — is one of those small skills that quietly makes programming less mysterious.

This guide walks through binary, octal, decimal, and hexadecimal: what a "base" actually means, how to convert by hand, why programmers lean on hex, and how the same number looks wildly different depending on the radix you write it in. If you just need the answer fast, the Number Base Converter does all four bases at once with live-linked fields, but understanding the mechanics is what lets you trust the output.

What "base" really means

A number base — or radix — is simply how many distinct digits you have before you have to carry into the next column. Base 10 has ten digits and the columns are powers of ten: 1, 10, 100, 1000. Base 2 has two digits (0 and 1) and the columns are powers of two: 1, 2, 4, 8, 16. Base 16 has sixteen digits, so after 9 it borrows letters: A=10, B=11, C=12, D=13, E=14, F=15, and the columns are powers of sixteen: 1, 16, 256, 4096.

The decimal number 13 written in three bases makes the pattern visible:

Binary (base 2): 1101 = 8 + 4 + 0 + 1
Octal (base 8): 15 = 8 + 5
Hex (base 16): D = 13

Same quantity, three notations. None is more "correct" — they are different alphabets for the same idea.

Why programmers live in hexadecimal

If computers run on binary, why is half of every memory dump written in hex instead? Because binary is unreadable past a few digits. A single byte is eight bits — 11111111 — and nobody wants to eyeball thirty-two of those in a row to read a pointer.

Hex is the shorthand. The reason it works so cleanly is that 16 is exactly 2⁴, so every hex digit maps to exactly four binary bits, with no overlap or remainder. F is always 1111, A is always 1010, full stop. That means you can read a 32-bit value as eight tidy hex digits instead of thirty-two anxious binary ones, and convert back groupwise in your head. A color like #1F8A4C is three bytes — red 1F, green 8A, blue 4C — and a programmer can expand any one of those to its eight-bit pattern instantly because the four-bits-per-digit relationship never wavers. This is documented in any computer architecture text as the standard rationale for hex notation; it is not a stylistic choice but a direct consequence of 16 being a power of 2. Octal (base 8 = 2³) does the same trick with three bits per digit, which is why Unix file permissions like 755 are written in octal — each digit packs exactly three permission bits.

Worked example: converting 255 into every base

Let me take a single value all the way around, because seeing it once removes the fear. I'll use 255, the maximum value of one byte and a number you'll meet constantly.

Decimal to binary (repeated division by 2): divide, write down the remainder, repeat with the quotient, then read the remainders bottom to top.

255 ÷ 2 = 127 r 1
127 ÷ 2 =  63 r 1
 63 ÷ 2 =  31 r 1
 31 ÷ 2 =  15 r 1
 15 ÷ 2 =   7 r 1
  7 ÷ 2 =   3 r 1
  3 ÷ 2 =   1 r 1
  1 ÷ 2 =   0 r 1

Read bottom-up: 11111111. Eight ones — every bit set, which is exactly what "the largest byte" should look like.

Binary to hex (group into fours): split 11111111 into 1111 1111. Each group of four is F. So 255 = 0xFF.

Decimal to octal (repeated division by 8): 255 ÷ 8 = 31 r 7, 31 ÷ 8 = 3 r 7, 3 ÷ 8 = 0 r 3. Bottom-up: 377.

So 255 is 11111111 in binary, 377 in octal, and FF in hex — and the reason FF and 377 are both so "round" is that 255 is one less than 256, a power of both 2 and 16. The first time this clicked for me was debugging a stuck status byte: the register read 0xFF, I expanded it to 11111111 in my head, realized every flag bit was high, and found a wiring short in about thirty seconds. Once you can flip between bases without a tool, the bug practically announces itself.

Negative numbers and two's complement

The conversions above assume positive integers. Negatives are where a number base converter earns its keep, because computers don't store a minus sign — they use two's complement. To encode −n in a fixed width: take the binary of n, flip every bit, then add 1.

For −1 in 8-bit: 1 is 00000001, flip to 11111110, add 1 to get 11111111. That's why 11111111 means 255 if you read it as unsigned but −1 if you read it as signed — same bits, two interpretations. This is also why setting a bit width matters before you type a negative number; without one, the math has no fixed-size byte to wrap around.

Doing it without the long division

Hand conversion is great for learning and for the occasional quick check, but for a 64-bit register dump or a 256-bit hash you want a tool that stores values exactly. Ordinary JavaScript loses precision above 2⁵³, so a naive converter will silently mangle 0xFFFFFFFFFFFFFFFF. A BigInt-backed converter keeps every digit, shows all four bases live-linked so editing one updates the rest, and adds bitwise AND/OR/XOR/shift across 8/16/32/64-bit widths.

If your input is plain text rather than a number — say you want the binary of the letters "Hi" instead of a numeric value — that's a different job handled by the Text to Binary converter, which encodes each character's code point. For numeric radix work, the base converter is the right tool, and now that you know what it's doing underneath, you can sanity-check anything it tells you.

Made by Toolora · Updated 2026-06-13