Hexadecimal and octal representation: Worked examples

The scenario matrix

Before solving anything, let's list every kind of conversion problem this topic can hand you. Think of it as a checklist — each worked example below is stamped with the cell it fills.

#	Case class	What makes it tricky	Example that covers it
A	Binary → hex, length is a multiple of 4	clean chop, no padding	Ex 1
B	Binary → hex/oct, length not a multiple of the group size	must pad the left with zeros	Ex 2
C	Hex/octal → binary → decimal	expand digits, watch letter digits A–F	Ex 3
D	Decimal → base by repeated division	remainders read bottom-up	Ex 4
E	Hex ↔ octal (different group sizes)	must route through binary	Ex 5
F	Degenerate / zero-ish inputs	value 0, a lone digit, leading zeros	Ex 6
G	Limiting / boundary value	the largest value a byte can hold	Ex 7
H	Real-world word problem	translate a story into a conversion	Ex 8
I	Exam-style twist	"10 in base b", or a mixed-up base claim to debunk	Ex 9

We'll walk them in order. Grab the group-size fact once and reuse it everywhere:

The figure above is your ruler for every example: the same 8-bit byte sliced two ways — into 4-bit slices (hex) and 3-bit slices (octal). Notice the octal slicing spills past the left edge, forcing a pad. That spill is the source of half the mistakes on this page.

Cell A — clean chop, no padding

Cell B — length not a multiple of the group size (padding)

Worked example Ex 2 —

$110110 1_{2} \to$ hex and octal Forecast: this string is 7 bits long. $7$ is not a multiple of $4$ (hex) nor of $3$ (octal). Guess: both conversions need left-padding. How many zeros each?

Hex — group into 4s from the right. $only 3 bits! 110 1101$ The leftmost group is short, so pad it on the left to 4 bits: $110 \to 0110$ . $60110 D 1101 \Rightarrow 6 D_{16}$ Why this step? Padding the left adds high-order zeros, which have value $0$ — the number is unchanged, but now every group is a full hex digit.
Octal — group into 3s from the right. $1 bit! 1 101101$ Pad the leftmost group: $1 \to 001$ . $100151015101 \Rightarrow 15 5_{8}$ Why this step? Same logic — high-order zeros are free; a 3-bit boundary must be respected. Verify: $6 D_{16} = 6 \cdot 16 + 13 = 96 + 13 = 109$ . $15 5_{8} = 1 \cdot 64 + 5 \cdot 8 + 5 = 64 + 40 + 5 = 109$ . And $110110 1_{2} = 64 + 32 + 8 + 4 + 1 = 109$ . ✓ All three agree.

Cell C — hex/octal → decimal via expansion (letter digits live here)

Cell D — decimal → base by repeated division

The figure shows the division ladder: read the remainder column upward to build the answer.

Cell E — hex ↔ octal, routed through binary

Worked example Ex 5 —

$3AC_{16} \to$ octal, without going via decimal Forecast: hex uses 4-bit chunks, octal uses 3-bit chunks — they don't line up. Guess: expand to binary, then re-slice into 3s. Should land on $165 4_{8}$ again (matching Ex 4).

Expand each hex digit to 4 bits. $3 \to 0011, A \to 1010, C \to 1100$ $\Rightarrow 00111010110 0_{2}$ Why this step? Each hex digit is exactly 4 bits — no arithmetic, just look-up.
Forget the old slice lines. Re-group into 3s from the right. $001110101100$ (Twelve bits, $12 = 4 \times 3$ , so it divides evenly — no extra padding.) Why this step? The bits carry the value; the slice size (4 vs 3) is just how we read them. Both readings describe the same binary, which is why binary is the universal middle-man.
Name each 3-bit group. $001 = 1, 110 = 6, 101 = 5, 100 = 4$ . $\Rightarrow 165 4_{8}$ Verify: matches Ex 4's answer $165 4_{8}$ exactly. ✓ (And we never touched decimal.)

Cell F — degenerate and zero-ish inputs

Worked example Ex 6 — the tricky little ones

Forecast: each of these looks "too small to have rules." Guess whether the rules still hold.

(a) Convert $0_{10}$ to hex. Repeated division: $0 \div 16 = 0 r 0$ . One remainder: $0$ . So $0_{10} = 0_{16}$ . Why? Zero has value $0$ in every base — the sum $\sum d_{i} b^{i}$ is empty/zero.

(b) Convert $0000010 1_{2}$ to hex. Group in 4s: $00000101 \to 0, 5 \Rightarrow 0 5_{16}$ , which is just $5_{16}$ . Why? Leading zeros are free; they neither add value nor change the low digit.

(c) Convert $7_{16}$ (a single hex digit) to binary. $7 = 011 1_{2}$ . A one-digit number still expands to its 4-bit pattern. Why? One hex digit is defined as 4 bits — write the leading zero to keep the block full when it matters, drop it when it doesn't.

(d) Convert $8_{10}$ to binary. $8 = 100 0_{2}$ . Here " $10$ -looking" traps don't apply — this is genuine decimal eight. Verify: (a) $0 = 0$ ✓. (b) $0 5_{16} = 5$ and $0000010 1_{2} = 5$ ✓. (c) $7_{16} = 7$ and $011 1_{2} = 4 + 2 + 1 = 7$ ✓. (d) $100 0_{2} = 8$ ✓.

Cell G — the boundary value (biggest a byte holds)

Cell H — a real-world word problem

Worked example Ex 8 — reading a colour code

Statement: A web colour is written #D35400 (this page's burnt-orange accent!). The last two hex digits 00 are the blue channel, the middle two 54 are green, and the first two D3 are red. Each channel is one byte (0–255). What is the red channel's decimal value, and is it more or less than half of maximum? Forecast: D3 — high digit is $D = 13$ , so this is a large-ish byte. Guess: over 200.

Isolate the red byte: $D3_{16}$ . Why this step? Each colour channel is exactly one byte = two hex digits; D3 are the first two.
Expand. $D = 13$ , so $D3_{16} = 13 \cdot 16 + 3 = 208 + 3 = 21 1_{10}$ . Why this step? Positional expansion of a 2-digit hex number.
Compare to half of max. Max is $255$ ; half is $127.5$ . Since $211 > 127.5$ , red is more than half-on — hence the warm, strong orange. Verify: $211$ in binary is $1101001 1_{2} = 128 + 64 + 16 + 2 + 1 = 211$ . ✓ And $211 < 255$ , a valid byte.

Cell I — the exam-style twist

Worked example Ex 9 — "

$10$ in every base" and a claim to debunk Statement (part 1): A quiz claims " $10$ always means ten." Evaluate $1 0_{2}$ , $1 0_{8}$ , $1 0_{16}$ . Forecast: each should equal its own base, not ten.

Expand each using the definition $d_{1} b^{1} + d_{0} b^{0}$ with $d_{1} = 1, d_{0} = 0$ . $1 0_{2} = 1 \cdot 2 + 0 = 2, 1 0_{8} = 1 \cdot 8 + 0 = 8, 1 0_{16} = 1 \cdot 16 + 0 = 16$ Why this step? " $10$ " is always one unit of the base plus zero units — i.e. the base itself. The claim is false except in base 10.

Statement (part 2): A student writes " $2F_{16} = 2 F_{8}$ because both are just grouped binary." Debunk it.

Test the octal claim. In octal, digits only go $0$ – $7$ ; there is no digit $F$ . So " $2 F_{8}$ " isn't even a legal octal number. Why this step? A digit must satisfy $0 \leq d_{i} < b$ . With $b = 8$ , $F$ (=15) is out of range.
Do it properly (via binary). $2F_{16} = 0010111 1_{2}$ ; re-slice in 3s: $00101111 \to 000101111 = 0, 5, 7 \Rightarrow 5 7_{8}$ . Verify: $2F_{16} = 2 \cdot 16 + 15 = 47$ ; $5 7_{8} = 5 \cdot 8 + 7 = 47$ . ✓ Equal values, different spellings — never equal digit-strings.

Recall Quick self-test — cover the answers

Which side do you pad when a bit-string is too short for its group? ::: The left (high-order zeros are free; right-padding doubles the value). $94 0_{10}$ in octal? ::: $165 4_{8}$ . Why can't you convert hex→octal by swapping digits directly? ::: 4-bit and 3-bit boundaries only re-align every 12 bits; route through binary. Largest 8-bit value in hex / decimal / octal? ::: $FF_{16} = 25 5_{10} = 37 7_{8}$ . Is $2 F_{8}$ a valid number? ::: No — octal digits are $0$ – $7$ , and $F = 15$ is out of range.

Connections

Hexadecimal and octal representation — the parent; this page drills its every corner case.
Binary number system — the common middle-man for all re-slicing.
Positional number systems and place value — the $\sum d_{i} b^{i}$ definition every expansion uses.
Two's complement and signed numbers — signed bytes are often shown as these same hex pairs.
Bitwise operations — hex makes each 4-bit mask instantly readable.
Memory addresses and byte addressing — why FF and byte boundaries matter in practice.
Boolean Algebra & Logic Gates — truth-table row indices are just these binary values.