Hexadecimal and octal representation: Question bank

Before we start, we need one symbol that every question below leans on.

The picture below shows this counting-from-the-right idea, and how grouping bits into $4$ s the correct way (from the right) versus the wrong way (from the left) changes which powers land in each group.

Figure — Hexadecimal and octal representation

Three anchors every question below leans on:

Recall The three ideas everything here tests

Place value grows from the right. In base $b$ , the rightmost digit is worth $b^{0} = 1$ , the next $b^{1}$ , then $b^{2}$ … So the " $4$ -bit" and " $3$ -bit" grouping must start at the right edge. See Positional number systems and place value.
The whole point of hex/octal is $16 = 2^{4}$ and $8 = 2^{3}$ . These are exact powers of two, so bits chop cleanly. $10$ is not a power of two, which is why decimal never gets this trick.
Binary is the universal middle-man. Hex groups $4$ bits, octal groups $3$ bits; $4$ and $3$ don't line up with each other, but both line up with binary.

True or false — justify

The base name tells you the value; the digit string alone never does

True. 11 could be three (binary), nine (octal), eleven (decimal), or seventeen (hex). Without the base subscript or prefix, a digit string is ambiguous.

10

" always means ten

False. In base

b

, "

10

" means

b

itself:

1 0_{2} = 2

1 0_{8} = 8

1 0_{16} = 16

. "Ten" is just what

10

happens to equal in base ten.

Adding a leading zero to a binary number's written form changes the value it represents

False — this item separates value from representation. Padding 110 to 0110 leaves the value unchanged (

6

either way), because the new digit sits in the

2^{3}

place and contributes

0 \cdot 2^{3} = 0

. Only the written width changes, which is precisely why left-padding is a legal step when filling out a

4

-bit or

3

-bit group.

Every 8-bit byte fits in exactly two hex digits

True.

8 = 2 \times 4

bits, and each group of

4

bits is one hex digit, so a byte is always exactly

2

hex digits (from 00 to FF).

Every 8-bit byte fits in exactly two octal digits

False.

8

is not a multiple of

3

. Grouping

8

bits into

3

s gives

⌈ 8/3 ⌉ = 3

octal digits (e.g. 11111111 =

37 7_{8}

), with the top group padded.

F

in hex is a variable standing for an unknown

False. In hex,

A

–

F

are fixed digits:

A = 10, \dots, F = 15

. 0xF is simply the number fifteen, never an unknown.

You can convert hex to octal by pairing up hex digits directly

False. A hex digit is

4

bits and an octal digit is

3

bits — they never line up. You must expand to binary first, then re-group into

3

Binary → hex and binary → octal group from the same side

True. Both group from the right, because place value (

2^{0}, 2^{1}, \dots

) starts on the right. Only the group size differs (

4

3

0 x F F

and

25 5_{10}

are the same number

True.

0 x F F = 15 \cdot 16 + 15 = 255

. They are two spellings of one value; the base changes the notation, not the quantity.

In repeated division, the first remainder becomes the leftmost digit

False. The first remainder is the

b^{0}

place — the rightmost digit. That's why you read remainders bottom-to-top.

Octal is more compact than hex

False. Hex packs

4

bits per symbol, octal only

3

, so hex is more compact. That's why modern hardware/code favours hex.

Spot the error

"To convert 11010110 to hex, group from the left: 1101|0110." What's wrong (if anything)?

Nothing is wrong here by luck — this byte has exactly

8 = 2 \times 4

bits, so left-grouping and right-grouping coincide. But the method is wrong: for any bit-count that isn't a multiple of

4

, grouping from the left misaligns the powers (see the figure above). Always group from the right.

"101 in binary is worth one hundred and one."

The digit string looks like decimal but isn't.

10 1_{2} = 1 \cdot 4 + 0 \cdot 2 + 1 = 5

. Reading a binary string as if it were decimal is a classic slip.

2 F_{16} = 2 \cdot 16 + 15 = 47

, so

F

is worth

15

and lives in the

1 6^{0}

place — but wait, shouldn't

F

be in the

1 6^{1}

place since it's bigger?"

The place is fixed by position, not by size.

F

is the rightmost digit, so it's in the

1 6^{0} = 1

place regardless of how large its value is. Place value depends only on where a digit sits.

"To pad 11 up to an octal group I write 110."

Padding must go on the left, giving 011, not the right. Right-padding multiplies the value (it appends a low bit); left-padding with zeros preserves the value. 011

= 3

, but 110

= 6

16 = 2^{4}

so one hex digit equals four octal digits."

No.

16 = 2^{4}

means one hex digit equals four binary digits (bits), not octal digits. Hex↔octal must route through binary.

"Since decimal is base 10 and

10 = 2 \cdot 5

, decimal groups binary into pairs of bits."

False reasoning. Grouping needs the base to be a pure power of two (

2^{k}

), not merely even.

10

is not

2^{k}

for any

k

, so no clean digit-by-digit binary↔decimal grouping exists.

"0b10 and 0o10 and 0x10 are all sixteen."

Only 0x10 is

16

. The prefixes set the base: 0b10

= 2

, 0o10

= 8

, 0x10

= 16

. In each, "

10

" means the base itself.

Why questions

Why do hex and octal exist at all, if decimal already works?

Because

16 = 2^{4}

and

8 = 2^{3}

align perfectly with bit boundaries, so binary↔hex/octal is pure regrouping — no arithmetic. Decimal (base

10

, not a power of two) needs full division, and long binary strings are error-prone to read directly.

Why must we group binary from the right, not the left?

Place values start at

2^{0}

on the right and grow leftward. A group of

4

bits only equals a clean single hex digit (worth

1 6^{i}

) when its boundaries sit on multiples of

4

counted from the right. Left-grouping cuts across those power boundaries — the second panel of the figure above shows the powers spilling across a boundary.

Why is padding with leading zeros always safe?

A leading zero sits in a higher place and contributes

0 \cdot b^{i} = 0

to the value. So it fills out a group to the required size (

4

3

bits) without changing the number at all.

Why route hex↔octal through binary instead of converting directly? Show it.

Hex groups bits in

4

s, octal in

3

4

and

3

share no common grouping, so there's no digit-to-digit map. Worked example:

2 F_{16}

→ expand each hex digit to

4

bits →

00101111

; now re-group the same bits into

3

s from the right →

00101111

… pad to

10111 1_{2} = 5 7_{8}

. The bits never changed — only where we drew the group boundaries. That's why binary is the middle-man.

Why does repeated division by the base peel off digits right-to-left?

Dividing

N

b

: every term

d_{i} b^{i}

with

i \geq 1

is divisible by

b

, so the remainder is exactly

d_{0}

(the

b^{0}

digit). The quotient is

N

"shifted right" one digit; repeating extracts

d_{1}, d_{2}, \dots

in order — hence read bottom-to-top.

Why do hex digits need letters

A

–

F

but octal digits don't?

Hex needs

16

distinct symbols but we only have

10

numerals (

0

–

9

), so we borrow letters for

10

–

15

. Octal needs only

8

symbols, and

0

–

7

already supply them.

Why is a hex digit "more information" than an octal digit?

A hex digit encodes

4

bits (

2^{4} = 16

possibilities); an octal digit encodes only

3

bits (

2^{3} = 8

). More bits per symbol means hex carries more information per character — see Memory addresses and byte addressing, which use hex for exactly this compactness.

Edge cases

What is

0_{2}

in hex and octal?

Zero in every base is just 0. There are no bits set, so no matter how you group, every group is 000... = 0.

How many hex digits does a single bit 1 need?

One. You pad on the left to 0001, which is the hex digit

1

. A shorter binary string just gets zero-padded up to a full group.

What's the largest value in one hex digit, and in one octal digit?

One hex digit maxes at

F = 15

(all four bits set, 1111). One octal digit maxes at

7

(111). Beyond these you need a second digit.

If a binary number has a bit-count that's a common multiple of

3

and

4

(like

12

), do left- and right-grouping ever agree?

When the count is an exact multiple of the group size there's no padding, so the boundaries happen to fall in the same places — but the count must match the group size (

4

for hex,

3

for octal). Right-grouping is never wrong; left-grouping is only accidentally right, so always group from the right.

Is 0xG a valid hex number?

No. Hex digits are

0

–

9

and

A

–

F

only.

G

would represent

16

, which is not a single digit in base

16

— it needs two digits, 0x10.

Does the byte 00000000 need padding to become hex?

No padding of content is needed since

8

is a multiple of

4

; it splits as 0000 0000 = 00. The leading zeros are already part of the fixed-width byte. It's simply

0 0_{16}

How is

- 1

(a negative value) written in hex on real hardware?

Hex itself has no minus sign in fixed-width storage; negatives use two's complement. In an 8-bit register

- 1

is stored as 11111111 = 0xFF. So 0xFF reads as

255

unsigned but

- 1

signed — same bits, the interpretation is chosen by context.

Is 0x80 positive or negative?

It depends on the interpretation, and that's the trap. The bits 10000000 are

128

unsigned, but as a signed 8-bit two's-complement value they mean

- 128

. Hex shows you the bit pattern, never the sign convention — you must know the width and signedness. See Two's complement and signed numbers.

Why can't you tell a signed value from its hex digits alone?

Hex is a faithful copy of the bits, and the bits don't carry a "signed or unsigned" flag — that decision lives in how the program or CPU treats the register. The same 0xFF is

255

- 1

depending purely on context.

Connections

Positional number systems and place value — the "place value grows from the right" rule every trap here relies on.
Binary number system — the universal middle-man.
Two's complement and signed numbers — why the same hex bits can mean a positive or a negative number.
Bitwise operations — where reading bits in hex groups pays off.
Memory addresses and byte addressing — why hex compactness matters in practice.
Boolean Algebra & Logic Gates — parent chapter.