Converting Between Number Bases
The Decimal And Binary System is something most people learn once in school and never really touch again until they run into an edge case at 2 AM. Here is how it actually works when you are doing it by hand. Decimal is base-10. You count from 0 to 9, and when you hit 9 and need one more, you roll over to 10. That carry-propagates through every position. Binary is base-2. You count from 0 to 1, and when you need one more, you roll over to 10. That is literally the entire system. It is not magical, it is just a different radix. Every digit in a binary number represents a power of 2 instead of a power of 10. The rightmost position is 2^0 = 1. The next is 2^1 = 2. Then 4, 8, 16, 32, 64, 128, and so on. To read a binary number, you add up the values for every position that has a 1 in it.
The Conversion Method I Actually Use
There are two directions and they are not the same operation. People mix them up constantly. To convert decimal to binary, you repeatedly divide by 2 and keep the remainders. You stop when the quotient reaches 0. Then you read the remainders from bottom to top. Let me give you a concrete example. Take the decimal number 156. 156 divided by 2 is 78 with a remainder of 0. 78 divided by 2 is 39 with a remainder of 0. 39 divided by 2 is 19 with a remainder of 1. 19 divided by 2 is 9 with a remainder of 1. 9 divided by 2 is 4 with a remainder of 1. 4 divided by 2 is 2 with a remainder of 0. 2 divided by 2 is 1 with a remainder of 0. 1 divided by 2 is 0 with a remainder of 1. Reading the remainders upward gives you 10011100. Check: 128 + 16 + 8 + 4 = 156. Correct.
To convert binary to decimal, you multiply each bit by its positional value and sum the results. With 10011100, that is 1×128 + 0×64 + 0×32 + 1×16 + 1×8 + 1×4 + 0×2 + 0×1 = 156.
Get the Full Details
A Quick Trick That Cuts Work Time in Half
Binary to decimal is fast if you just group the bits into sets of four starting from the right. Each group maps directly to one hexadecimal digit, and you can memorize that mapping in about ten minutes. 1001 maps to 9, 1100 maps to C. So 10011100 is 9C in hex. From there, 9×16 + 12 = 144 + 12 = 156. This is especially useful when you are reading memory dumps or debugging at the bit level and need to convert on the fly without a calculator. Last month I was parsing a custom network protocol that encoded timestamps as binary fractions rather than integers. Every value was a 32-bit fixed-point number with the binary point sitting between bit 16 and bit 17. The documentation said "binary fraction format" but gave zero examples of how to actually extract the decimal value from it. I wrote a converter that treated the raw integer as if the point were at the end, which gave wildly wrong numbers. The fix was to divide the integer value by 65536 (2^16) to shift the binary point back into place. For example, the raw 32-bit value 33554432 (which looks like 0x02000000) actually represents exactly 512.0 seconds when you account for the fractional position. Without that division step, everything downstream was off by a factor of 65536.
This is the kind of thing you will almost certainly encounter if you work with embedded systems, old file formats, or hardware register maps. The documentation rarely spells out where the implied binary point actually sits.
Things Beginners Get Wrong
The biggest mistake is assuming binary conversion is always clean. It is not. Converting a decimal fraction like 0.625 to binary works fine because it is a sum of powers of 2. But something like 0.1 in decimal produces an infinitely repeating binary fraction: 0.0001100110011... This is not a quirk of your conversion method. It is a fundamental property of base-2 representation. Any system that stores floating-point numbers in binary will have this issue, including nearly every programming language you will ever use. Another common error is treating leading zeros as significant when they are not. The binary number 000101 and the binary number 101 are identical in value. Leading zeros only matter when you are enforcing a fixed bit-width like a uint8 or uint16 type, where padding tells the parser how many bits to consume.
When This Approach Breaks Down
The manual conversion methods I described work fine for small numbers and one-off calculations. They become impractical when you are dealing with 64-bit values or when you need to convert thousands of numbers in a batch. In those cases, writing a script is faster and less error-prone. Even a five-line Python script using the built-in bin() and int() functions will handle this in milliseconds versus minutes of hand calculation. There is also the question of negative numbers. The division-by-2 method only works for positive integers. Once you introduce negatives, you need to pick a representation scheme: two's complement, sign-magnitude, or ones' complement. Two's complement is the standard in virtually all modern systems, but the documentation for a given protocol or file format might not tell you which one it uses. If you assume the wrong one, your converted values will be completely wrong and you will spend hours trying to debug something that was a representation error from the start.
Why This Still Matters
Even though nobody does manual conversions anymore in day-to-day work, understanding the Decimal And Binary System is still necessary if you want to do anything below the abstraction layer. Memory addressing, bitmasking, network protocols, compression formats, color channels in image files, and cryptographic operations all rely on you being able to think in binary without getting confused. The conversion process itself is trivial. The part that trips people up is forgetting that the system exists and not realizing they need it until their program reads a byte and the output makes no sense.
