Base conversion is one of those skills that feels intimidating until you've done it manually once or twice, after which it becomes almost mechanical. Here's the actual step-by-step process, worth knowing even if you'll usually let a tool do it for you afterward.
Step 1: Understand What a Base Actually Means
Decimal (base 10) uses ten digits, 0 through 9, and each position represents a power of ten. Binary (base 2) uses two digits, 0 and 1, and each position represents a power of two. Hexadecimal (base 16) uses sixteen symbols, 0 through 9 and then A through F for the values 10 through 15, and each position represents a power of sixteen.
The core idea that makes conversion possible is that any number, regardless of which base it's written in, represents the same underlying quantity. You're not changing the value, you're changing the notation.
Step 2: Convert Binary to Decimal
To convert binary to decimal, multiply each digit by the power of two corresponding to its position, counting from the right starting at zero, then add the results. Take the binary number 1011. From right to left, that's 1×2⁰ + 1×2¹ + 0×2² + 1×2³, which is 1 + 2 + 0 + 8, which equals 11 in decimal.
Wikipedia's page on binary numbers has a solid explanation of positional notation if this step doesn't click immediately, including worked examples with more digits.
Step 3: Convert Decimal to Binary
Going the other direction, repeatedly divide the decimal number by 2 and record the remainder at each step, then read the remainders from bottom to top. Converting 11 back to binary: 11 divided by 2 is 5 remainder 1. 5 divided by 2 is 2 remainder 1. 2 divided by 2 is 1 remainder 0. 1 divided by 2 is 0 remainder 1. Reading the remainders bottom to top gives 1011, confirming the round trip.
Step 4: Convert Between Binary and Hexadecimal
This is the conversion programmers do most often, and it's faster than going through decimal because binary and hexadecimal have a clean relationship: every hex digit corresponds to exactly four binary digits. Group your binary number into sets of four from the right, pad with leading zeros if needed, then convert each group independently.
Take the binary number 10110111. Split into groups of four: 1011 and 0111. 1011 converts to B (11 in decimal). 0111 converts to 7. So 10110111 in binary is B7 in hexadecimal. Wikipedia's hexadecimal page has a full digit-to-digit conversion table if you want it handy for reference.
Step 5: Watch Out for Negative Numbers
Negative numbers in binary are where hand conversion gets genuinely tricky, because computers typically use a representation called two's complement rather than a simple sign bit. In two's complement, you invert every bit of the positive version of the number and add one. This is also why the range of representable negative numbers in a fixed bit width is slightly larger than the range of positive numbers, an asymmetry that trips people up the first time they encounter it.
If you're converting negative values by hand for something like a networking or systems programming context, it's worth explicitly confirming the bit width, 8-bit, 16-bit, 32-bit, since the same bit pattern means a different value depending on how many bits you're assuming.
Step 6: Verify With a Tool
Once you understand the mechanics, verifying by hand for anything beyond a handful of digits stops being a good use of time. The free Scientific Calculator on EvvyTools includes base conversion with the intermediate steps visible, which is useful both for checking your hand work and for catching the kind of bit-width mismatch described above before it causes a bug somewhere downstream.
There's a broader look at where calculators quietly diverge from what users expect, covering order of operations and angle mode in addition to base conversion, in this piece on why two calculators can give different answers to the same problem.
Why It's Worth Knowing By Hand at All
Tools handle base conversion instantly and correctly, so the manual process isn't something you'll use daily. But understanding what's actually happening when a byte gets displayed as a two-character hex code, or when a permission flag gets represented as an octal number, makes debugging genuinely faster. You stop treating base conversion as opaque magic and start being able to eyeball whether a hex value looks roughly right for the binary pattern it's supposed to represent, which is a small but real debugging superpower.
Where This Shows Up in Real Code
Hex shows up constantly in places you might not immediately connect to base conversion: color codes in CSS and design tools are hexadecimal, memory addresses in debuggers are typically printed in hex, and MAC addresses and much of low-level networking data is represented in hex pairs. Binary shows up explicitly in bitwise operations, permission flags (the classic chmod 755 in Unix is actually an octal representation of three binary permission triplets), and anywhere a program is packing multiple boolean flags into a single integer.
Recognizing a hex or binary value on sight, and having a rough sense of its decimal scale, is genuinely useful for reading logs and debugging output quickly. A memory address like 0x7FFE is clearly a small offset, while one like 0x7FFFFFFF is suspiciously close to the maximum value of a 32-bit signed integer, which is itself a common source of overflow bugs. That kind of pattern recognition only develops once you've done a few conversions by hand and internalized roughly how the digits map to magnitude.
Octal Deserves a Quick Mention Too
Base 8, octal, is less common today than it used to be, but it still shows up in Unix file permissions and in some older systems. The conversion logic is the same as binary and hex, just with eight symbols (0 through 7) instead of two or sixteen, and each position representing a power of 8 instead of 2 or 16. If you can convert between binary and hex confidently, extending the same logic to octal is mostly a matter of grouping binary digits into sets of three instead of four, since 8 is 2 cubed the same way 16 is 2 to the fourth.
A Worked Example End to End
Let's take the decimal number 202 through binary and hex, start to finish. Dividing repeatedly by 2: 202 -> 101 r0, 101 -> 50 r1, 50 -> 25 r0, 25 -> 12 r1, 12 -> 6 r0, 6 -> 3 r0, 3 -> 1 r1, 1 -> 0 r1. Reading the remainders bottom to top gives 11001010. Grouping into fours from the right: 1100 and 1010, which convert to C and A respectively, giving CA in hex. You can verify this quickly: C is 12, A is 10, and 12×16 + 10 = 192 + 10 = 202, matching the original decimal value. Working through one full example like this, checking your own arithmetic at each step, is the fastest way to make the whole process feel mechanical instead of intimidating, and it's worth repeating with two or three of your own numbers until the grouping-into-fours step stops requiring conscious thought.
Top comments (0)