Number Base Converter — Binary, Octal, Decimal & Hex

Converting between number bases by hand is a rite of passage in every programming course, and a tool you still reach for years later when debugging a bitmask, a file permission value, or a color hex code. This snippet keeps four inputs — binary, octal, decimal, and hexadecimal — permanently in sync: type in any one of them and the other three update instantly using JavaScript's own radix-aware number parsing and formatting, not a hand-rolled conversion algorithm.

parseInt and toString do the real conversion work

The core conversion logic is exactly two built-in calls. parseInt(raw, sourceBase) reads the input string as a number in whichever base the user typed into, and value.toString(targetBase) re-renders that same numeric value into any other base's string representation. This is deliberate: JavaScript's Number type and these two methods already implement correct, well-tested radix conversion, so there is no reason to hand-write digit-by-digit division-and-remainder logic that could introduce subtle bugs. The interesting engineering is entirely in validation and UI synchronization, not in the math itself.

Per-base input validation before conversion

Each base has a different valid character set, checked with a dedicated regular expression before any conversion is attempted: /^[01]*$/ for binary, /^[0-7]*$/ for octal, /^[0-9]*$/ for decimal, and /^[0-9a-fA-F]*$/ for hex. This catches invalid input — typing "2" into the binary field, or "G" into the hex field — before it reaches parseInt, which would otherwise silently parse only the valid leading digits and produce a confusingly wrong number rather than an obvious error. The offending row is marked with a red border and the status line names exactly which base rejected the input.

Avoiding an infinite update loop

Because every input listens for changes and rewrites the other three fields, a naive implementation would trigger the hex field's own input handler when the converter programmatically sets its value, cascading into every other field again. updateFrom(sourceBase) sidesteps this entirely by writing to inputs[b].value directly — a plain DOM property assignment — rather than calling any method that dispatches a synthetic input event, so only the field the user actually typed into ever fires the update function.

A 32-bit range guard

Values above 4294967295 (2³²−1) are rejected with an explicit message rather than allowed to silently produce Infinity or lose precision, since Number.prototype.toString(radix) on values beyond safe integer precision can behave unpredictably. This keeps the tool honest about its limits instead of quietly returning a wrong answer for very large inputs.

The 8-bit visual breakdown

Below the four synced inputs, renderBits() takes the current value modulo 256 (via a bitwise & 0xff) and extracts its low 8 bits one at a time using n & 1 followed by a right shift, building an array of individual bit values. Each bit renders as its own cell labeled with the binary place value it represents (128, 64, 32, ... down to 1), with "on" bits highlighted in a distinct color. This makes bitwise concepts — which single bit toggling produces which change in decimal, how a byte's most significant bit relates to values 128 and above — visible rather than abstract, which is exactly the kind of thing that is much easier to understand by watching a highlighted cell flip than by reading an explanation of it.