# Number bases and base conversion

*Turning any number into any base by hand*

Base conversion rewrites the same number in a different base by regrouping its value into that base's place values: divide by the base and collect remainders (or subtract the largest place value at a time), and group binary digits by 3 for octal or by 4 for hexadecimal.

Group: Number & logic
URL: https://digiwleea.wleeaf.dev/learn/number-bases/

> **KEY:** This page is the **conversion toolkit** for the Number & logic group. [Binary](https://digiwleea.wleeaf.dev/learn/binary/) and [hexadecimal](https://digiwleea.wleeaf.dev/learn/hexadecimal/) showed you what each base *is*; here you learn to move a value **between** bases quickly and by hand, including octal, fractions, and one trick for spotting an unknown base. The [base converter](https://digiwleea.wleeaf.dev/tools/base-converter/) does any of these conversions instantly.

Recall the one idea every base shares. In [binary](https://digiwleea.wleeaf.dev/learn/binary/) each column is worth twice the one to its right (`1, 2, 4, 8, ...`), and in [hexadecimal](https://digiwleea.wleeaf.dev/learn/hexadecimal/) each column is worth sixteen times the one to its right. In general, in **base b** the columns are worth `b^0, b^1, b^2, ...` going left, and each digit says how many of that column you have. To read `4123` in base 5, for instance, you compute `4*125 + 1*25 + 2*5 + 3*1 = 538`. The value is the same number; only the writing changes.

> **TIP:** A digit is never allowed to reach the base: the largest digit in base `b` is `b - 1`. That is why base 2 uses only `0` and `1`, base 8 uses `0`-`7`, and base 16 has to borrow letters (`A`-`F`) for the digits worth ten to fifteen. Spotting the largest digit in a number puts a floor under its base.

## Decimal to binary, two ways

Reading binary is easy (add up the column worths under each `1`). Going the other way, from a decimal number to its bits, has two reliable methods. Learn both: one is faster when you can eyeball the powers of two, the other is mechanical and never fails.

**Method 1: subtract the largest power of two.** Find the biggest power of two that fits, put a `1` in that column, subtract it, and repeat on what is left. Take `13`. The biggest power of two that fits is `8`, leaving `5`; the biggest that fits `5` is `4`, leaving `1`; the biggest that fits `1` is `1`, leaving `0`. So `13 = 8 + 4 + 1`, which lights the `8`, `4`, and `1` columns:

```
13 = 8 + 4 + 1 = 1*8 + 1*4 + 0*2 + 1*1 = 1101 (binary)
```

This method shines when a number sits right next to a power of two. `257` is just `256 + 1`, and `256 = 2^8`, so only the `256` column and the `1` column are lit and everything between them is `0`:

```
257 = 256 + 1 = 2^8 + 2^0 = 100000001 (binary)
```

**Method 2: repeated division by two.** Divide the number by `2`, write down the remainder (`0` or `1`), then divide the quotient by `2` again, and keep going until the quotient is `0`. The remainders are the bits, but they come out **least-significant first**, so you read them from the **bottom up**. For `13`:

1. `13 / 2 = 6` remainder **1**  (the LSB)
2. `6 / 2 = 3` remainder **0**
3. `3 / 2 = 1` remainder **1**
4. `1 / 2 = 0` remainder **1**  (the MSB)
5. Read the remainders bottom to top: `1101`. Same answer as method 1.

> **TIP:** Use method 1 when the number is small or clearly near a power of two (`257`, `1023`, `64`); use method 2 for an arbitrary value like `217` where hunting for powers is slower than just dividing. Both always agree, so you can check yourself by doing a value once each way.

**Q (Try it):** Convert `100` to binary using BOTH methods, and confirm they match.

**A:** Subtract powers: `64` fits (leaves `36`), `32` fits (leaves `4`), `4` fits (leaves `0`), so `100 = 64 + 32 + 4` and the lit columns are `64 32 . . 4 . .`, giving `1100100`. Divide by two: `100->50` r0, `50->25` r0, `25->12` r1, `12->6` r0, `6->3` r0, `3->1` r1, `1->0` r1; bottom-up that is `1100100`. Both give **`1100100`** (check: `64 + 32 + 4 = 100`).

## Octal: base 8, three bits at a time

**Octal** is base 8, with digits `0`-`7`. It matters for the same reason hex does: `8 = 2^3`, so **one octal digit is exactly three bits**, just as one hex digit is exactly four bits (`16 = 2^4`). That makes converting between binary and octal a pure lookup with no arithmetic, using this table for each 3-bit group:

| binary | octal |
| --- | --- |
| 000 | 0 |
| 001 | 1 |
| 010 | 2 |
| 011 | 3 |
| 100 | 4 |
| 101 | 5 |
| 110 | 6 |
| 111 | 7 |

_Every 3-bit pattern maps to one octal digit. This is the whole binary <-> octal conversion._

**Binary to octal:** group the bits into threes **from the right** (pad the left with zeros if needed) and replace each group with its digit. **Octal to decimal:** use place values that are powers of eight (`1, 8, 64, ...`). Take octal `712`:

```
712 (octal) = 7*64 + 1*8 + 2*1 = 448 + 8 + 2 = 458 (decimal)
```

The same value `458` in binary is `111001010`. Group it by threes from the right, `111 001 010`, and you read `7 1 2`, back to octal `712`. Group the *same* bits by fours instead, `1 1100 1010`, pad to `0001 1100 1010`, and you read `1 C A`, so it is `0x1CA` in hex. One binary string, three groupings, three readable forms:

```
111001010 (binary) = 712 (octal) = 0x1CA (hex) = 458 (decimal)
```

> **KEY:** This is the real reason octal and hex exist: because `8` and `16` are powers of two, converting to or from binary is just **grouping bits**, never long division. Octal packs bits by threes, hex by fours; both turn an unreadable row of `0`s and `1`s into a short string a human can scan.

_Circuit diagram: One octal digit is exactly three bits. Set b2 b1 b0 (their worths are 4, 2, 1) and the pattern spells a single octal digit 0-7. Open it in the lab, dial in a few patterns, and name the octal digit each one spells._

**Q (Try it):** Convert the byte `11010110` to octal and to hex by grouping. Then find its decimal value to check.

**A:** Octal (group by 3 from the right): `11 010 110` -> pad to `011 010 110` -> `3 2 6`, so **`326` octal**. Hex (group by 4): `1101 0110` -> `D 6`, so **`0xD6`**. Decimal check: `128 + 64 + 16 + 4 + 2 = 214`; octal `326` is `3*64 + 2*8 + 6 = 214`, and hex `0xD6` is `13*16 + 6 = 214`. All agree.

## Digits after the point: fractions

The place-value idea keeps working to the right of the point, where the powers go negative. In binary the first fractional column is `2^-1 = 1/2`, the next is `2^-2 = 1/4`, and so on, each half the size of the one before it:

| binary column | value |
| --- | --- |
| 2^-1 | 0.5 |
| 2^-2 | 0.25 |
| 2^-3 | 0.125 |
| 2^-4 | 0.0625 |

_Fractional binary columns. So 0.101 (binary) = 0.5 + 0.125 = 0.625._

To convert a decimal fraction **to** binary, run the mirror image of the division method: repeatedly **multiply by two** and record the whole-number part (`0` or `1`) that pops out each time, discarding it before the next step. Unlike the integer method, these digits come out **most-significant first**, so you read them **top to bottom**. Take `0.625`:

1. `0.625 * 2 = 1.25` -> digit **1**, keep `0.25`
2. `0.25 * 2 = 0.5` -> digit **0**, keep `0.5`
3. `0.5 * 2 = 1.0` -> digit **1**, fraction is now `0`, stop
4. Read top to bottom: `0.101` (check: `0.5 + 0.125 = 0.625`).

That one terminated because `0.625` is an exact sum of halves. Most decimal fractions are **not**, so the multiply-by-two loop never hits zero and the binary digits **repeat forever**. `0.2` is the classic example: multiplying by two gives digits `0, 0, 1, 1` and then the fraction returns to `0.2`, so the block `0011` repeats without end.

```
0.2 (decimal) = 0.00110011001100... (binary), the block 0011 repeating
```

> **WARN:** Common mistakes to avoid: (1) integer remainders read **bottom-up**, but fractional digits read **top-down**, so do not mix the directions. (2) Group bits for octal/hex **from the right**, not the left, padding the leftmost group with zeros. (3) A tidy decimal fraction like `0.1` or `0.2` does **not** terminate in binary, which is exactly why `0.1 + 0.2` is not quite `0.3` in a computer. (4) Always mark the base when it is not obvious, since `101` could be decimal, binary, or octal.

## How big is 2^10? Kilobytes vs kibibytes

Because memory sizes are counts of bits and addresses, they land on powers of two, and a few of those powers sit suspiciously close to the round decimal numbers people already use. `2^10 = 1024` is almost `1000`, `2^20 = 1048576` is almost a million, and `2^30 = 1073741824` is almost a billion. That near-miss created a naming muddle worth untangling:

| power of 2 | binary prefix | exact value | SI prefix (approx) |
| --- | --- | --- | --- |
| 2^10 | 1 kibi (Ki) | 1024 | kilo ~ 1000 |
| 2^20 | 1 mebi (Mi) | 1048576 | mega ~ 1000000 |
| 2^30 | 1 gibi (Gi) | 1073741824 | giga ~ 1000000000 |

_The binary prefixes (kibi/mebi/gibi) are exact powers of two; the SI prefixes (kilo/mega/giga) are exact powers of ten. They are close but not equal._

So a **kibibyte** (`1 KiB`) is exactly `1024` bytes (`2^10`), while a **kilobyte** in the strict SI sense is `1000` bytes. People long said "kilobyte" loosely for the `1024` value, and the `Ki`/`Mi`/`Gi` prefixes were introduced to say "the power-of-two one" without ambiguity. In this course, memory and address sizes are always powers of two, so `1K` of memory means `1024` locations.

> **KEY:** This is why a `10`-bit address selects exactly `1024` (`2^10`) locations, and why capacities come in `1024`-step jumps. When you reach [buses](https://digiwleea.wleeaf.dev/learn/buses/) and [RAM](https://digiwleea.wleeaf.dev/learn/ram/), an `n`-bit address bus reaches `2^n` cells, so knowing that `2^10 = 1024`, `2^16 = 65536`, and `2^20 = 1048576` lets you size a memory at a glance.

## Finding an unknown base

Sometimes an arithmetic statement is written in an unknown base and you must find it. Suppose someone claims `24 + 17 = 40` is correct, but plainly not in decimal (`24 + 17` is `41` in decimal). Since the digit `7` appears, the base must be at least `8`. To pin it down, call the base `b`, write each numeral in terms of `b`, and solve.

1. Expand each numeral: `24` is `2b + 4`, `17` is `1b + 7`, and `40` is `4b + 0`.
2. Set the sum equal: `(2b + 4) + (b + 7) = 4b`, which is `3b + 11 = 4b`.
3. Solve: subtract `3b` from both sides to get `11 = b`, so the base is **11**.

```
check: 24 = 2*11+4 = 26, 17 = 1*11+7 = 18, 26 + 18 = 44 = 4*11 = 40 (base 11)
```

The check confirms it: in base 11, `24` is `26`, `17` is `18`, they sum to `44`, and `40` in base 11 is `4*11 = 44`. The whole method is: turn each numeral into a polynomial in the base, form the equation the statement asserts, and solve for `b`.

**Q (Try it):** The statement `15 + 15 = 32` is correct in exactly one base. Which base, and how do you know?

**A:** Let the base be `b`. Then `15` is `b + 5` and `32` is `3b + 2`, so `(b + 5) + (b + 5) = 3b + 2`, i.e. `2b + 10 = 3b + 2`, giving `b = 8`. Check in base 8: `15` is `13`, `13 + 13 = 26`, and `32` in base 8 is `3*8 + 2 = 26`. (The digit `5` also requires the base to be at least `6`, and `8` clears that.)

> **KEY:** Base conversion is the everyday plumbing of digital work: you write bytes in [hexadecimal](https://digiwleea.wleeaf.dev/learn/hexadecimal/), size memories in powers of two, and switch between forms constantly. The mechanics are just place value applied backwards, so once these methods are automatic you never have to trust a converter blindly.

### FAQ

**Q:** How do you convert a decimal number to binary?

**A:** Two ways. Subtract the largest power of two that fits, put a `1` in that column, and repeat on the remainder (`13 = 8 + 4 + 1 = 1101`). Or divide the number by `2` repeatedly, writing each remainder, then read the remainders from the bottom up (`13`: remainders `1,0,1,1` read upward give `1101`). Both give the same bits.

**Q:** What is octal and how do you convert binary to octal?

**A:** Octal is base 8, using digits `0`-`7`. Because `8 = 2^3`, one octal digit is exactly three bits, so you convert by grouping the binary digits into threes from the right (padding the left with zeros) and replacing each group with its digit: `111001010` becomes `111 001 010`, which is `712` in octal.

**Q:** What is the difference between a kilobyte (KB) and a kibibyte (KiB)?

**A:** A kibibyte (`KiB`) is exactly `1024` bytes, which is `2^10`, while a kilobyte in the strict SI sense is `1000` bytes. The binary prefixes kibi/mebi/gibi (`2^10`, `2^20`, `2^30`) were introduced because people had long used kilo/mega/giga loosely for the nearby power-of-two values, and the two are close but not equal.

**Q:** Why is 0.1 not exact in binary?

**A:** Converting a decimal fraction to binary means repeatedly multiplying by two and recording the whole-number part; for `0.1` (and `0.2`) that loop never reaches zero, so the binary digits repeat forever and no finite number of bits stores the value exactly. That is why `0.1 + 0.2` is not quite `0.3` in floating-point arithmetic.