Why this conversion needs two steps, not one
Every other converter on this site goes between two formats that both describe the same value directly — hex and decimal are both just numbers, hex and binary are both just numbers. RGB is different: it's written as three independent decimal numbers, one per channel, not a single packed value at all. Binary, meanwhile, is a single bit pattern. To get from "three separate numbers" to "one bit pattern," something has to do the packing first — and that something is hex, which is why this page exists as an explicit two-step chain rather than a single formula, the way the site's other converters work.
Step 1: RGB to hex
Each RGB channel (0-255) becomes exactly one 2-digit hex byte, and the three bytes are concatenated in order: rgb(59, 130, 246) becomes 3B, 82,F6, joined into #3B82F6. This step is identical to what theHex ↔ RGB converter does, and it's the step that actually performs the "packing" — three independent numbers become one continuous string of digits.
Step 2: hex to binary
Once the value is packed into hex, converting to binary is direct and mechanical: each hex digit maps to exactly 4 bits, with no arithmetic beyond a lookup. 3 is 0011,B is 1011, and so on — six hex digits give 24 bits total, the same relationship covered on the Hex ↔ Binary page. Padding every digit to a full 4 bits, rather than dropping leading zeros the way an arbitrary-precision number normally would, is what keeps each channel's 8 bits aligned to its own byte in the final pattern.
Why the byte boundaries matter here specifically
An unpadded binary conversion of 0x3B82F6 would produce a 22-bit string, not 24 — technically a correct value for that integer, but it destroys the one thing this page exists to show: exactly which 8 bits belong to red, which 8 to green, and which 8 to blue. Because an RGB color is always three fixed-width bytes regardless of how small any individual channel's number is, this page pads every channel to a full byte before concatenating, so the boundaries in the 24-bit output always land in the same three places: bits 1-8, 9-16, and 17-24.
A worked example, both directions
Going forward: rgb(255, 0, 0) (pure red) becomes #FF0000 in step one, then 11111111 00000000 00000000 in step two — the first byte all ones, the other two all zeros, visibly showing that only the red channel is active. Going backward, a 24-bit string is split into three 8-bit bytes, each byte converted to a 2-digit hex pair, and the three pairs combined back into a single hex color before being split back into RGB channel values — the exact reverse of the forward chain, one link at a time.
Where this kind of chained conversion actually comes up
Graphics and embedded programming both work directly with packed pixel formats — a 24-bit or 32-bit integer holding a full color, read out of a framebuffer, a texture, or a hardware register. Understanding which bit ranges correspond to which color channel is a genuinely common task in that kind of code, and it's exactly the gap between "I have an RGB value" and "I need to see its raw bit pattern" that going through hex as an explicit intermediate step is meant to close, without needing to open two separate calculators and copy a value between them by hand.